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INTEGRATED BUSINESS SYSTEM FOR WEB BASED 
TOBCOMMONI CAWQWg MANAGEMENT 

The present invention relates generally to 
method of doing business over the public Internet, and, 
particularly, to providing enterprise management tools 
to customers of a telecommunications service provider 
over the Internet. 

The public Internet was created as ARPANET , 
an initiative of the Defense Advanced Research Projects 
Agency (DARPA) to connect computers for the exchange of 
data, and to enable command and control functions to be 
exchanged in case of a nuclear war. In the 1970s, it 
was split into military and civilian networks, with the 
civilian network managed by the National Science 
Foundation (NSF) . In the early 19 80s, the Secretary of 
Defense mandated the TCP/IP network protocol, and the 
NSF gradually turned control of what was now referred 
to as the public Internet to universities, independent 
agencies and commercial service providers. During this 
time, the Internet was used primarily for scientific 
and academic purposes. With the adoption of HTML and 
the development of graphical browsers, the public 
Internet began to shift from a technical character set 
form of communication, to a delivery medium for all 
types of content over the World Wide Web (Web) and 
commercial enterprises entered this segment of the 
Internet to do business over the rapidly developing Web 
environment. Initial methods of doing business were 
focused on using the Web as an alternate to existing 
direct mail, magazine or television methods of doing 
business, in which goods were advertised and sold, or 
content was delivered via the Web in a manner similar 
to existing methods of doing business. 
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During this same period of time, the 
telecommunications industry began to provide a greater 
percentage of the Internet capacity, both in terms of 
high speed lines between web sites, and between the 
5 individual consumers and small business who connect to 

the Web through a local telephone Central Office (CO) 
and an Internet service provider. 

Simultaneously, the telecommunications 
industry recognized that its larger customer were 

10 interested in managing portions of their own business 

provided by the telecommunications enterprise, and 
began to make some of their management tools available 
to their customers. In these conventional customer 
enabled management systems, a connection was made with 

15 a large legacy system via a dial-up connection from a 

customer owned personal computer or work station. This 
connection frequently, although not always, emulated a 
terminal addressable by the legacy system. The dial-up 
access required custom software on the customer 

20 workstation to provide dial-up services, communication 

services, emulation and/or translation services and 
generally some resident custom form of the legacy 
application to interface with the mid range or main 
frame computer running the legacy system. 

25 There were several problems associated with 

this approach: 

First, the aforementioned software is very 
hardware specific, and customers generally have a wide 
range of workstation vendors, which required an 

30 extensive inventory of software for distribution, and 

generally, intensive customer hand holding through 
initial setup and installation before reliable and 
secure sessions were possible. If the customer 
hardware platform changed through an upgrade, most of 

35 these issues needed renegotiation. 
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Secondly, dial-up, modem, and communications 
software interact with each other in many ways which 
are not always predictable to a custom application, 
which required extensive trouble shooting and problem 
5 solving capacity for an enterprise wishing to make the 

legacy system available to the customer, particularly 
where various telephone exchanges, dialing standards or 
signal standards were involved. 

Third, when an enterprise wished to make more 

10 than one system available to the customer, the custom 

application for one legacy system was not able to 
connect to a different legacy system, and the customer 
had to logoff and logon to switch from one to the 
other. The delivery technology used by the two legacy 

15 systems was frequently different, which required 

different interface standards. 

Finally, the security and entitlement 
features of the various legacy systems were frequently 
quite different, and varied from system to system and 

20 platform to platform. 

In the context of telecommunications services 
and products offered by large telecommunications 
network service providers for their customers, the 
assignee of the present invention, MCI, has deployed an 

25 MCI ServiceView ("MSV") platform comprising a number of 

independent legacy systems enabling dial-up 
connectivity for those customers desiring to obtain the 
following network management service and reporting data 
pertaining to their telecommunications networks: 

30 priced call detail data and reporting; toll-free 

network manager "800NM" call routing data; outbound 
network management data; trouble ticket information; 
fault manager alarms. Limited interactive toll free 
network control is additionally supported whereby 

35 customers may change the configuration of their toll- 

free networks and "virtual" networks, i.e., Vnet 
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networks. In addition to the MSV platform, the present 
assignee has implemented a variety of stand alone 
applications including: a Traffic View system enabling 
customers to perform real-time network traffic 
monitoring of their toll-free networks, and obtain 
near -real time call detail data and reports, and, a 
"Hyperscope" reporting system for providing reports on 
the performance if customers 1 Broadband (data) 
networks . 

More particularly, MCI's ServiceView platform 
("MSV") provides for the generation of Toll-free 
Network Management data, priced call detail 
("Perspective") data for usage analysis and trending, 
each of which requires a different reporting mechanism 
due to the nature of the data being presented. Such 
reporting systems typically do not provide any report 
customization or presentation options for the customer, 
and any reporting customization is provided by an 
application specific program running on the client 
workstation. Furthermore, such systems do not readily 
provide for the scheduling of periodic or ad hoc "one- 
shot" reports. 

AT&T provides a "Customer Direct" offering, a 
first part of which is known as the Network 
Administration System (NAS) , and is developing a second 
part, known as Service Request System (SRS) . The NAS 
program uses a personal computer, a Windows based GUI 
and analog dial-up access at 9.6 Kbps to AT&T's legacy 
network switch control systems. When completed, the 
SRS offering will use the same type of dial-up platform 
and enable an AT&T customer to order services and 
features from their desk -top personal computer. 

Sprint provides several legacy systems via 
the Insite service offerings, including Insite PC, 
Insite ACT and is in the process of developing the 
Sprint Insite Executive network management program, all 
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making use of a customers personal computer and a dial- 
up connection. Sprint also announced on September 17, 
1996, the Sprint InTouch(SM) product which would enable 
a customer to open, view, note or close trouble 
5 tickets. 

These prior art systems, with the excepting 
of InTouch(SM) all suffer from the aforementioned 
problems with dial-up telephone connections and legacy 
applications. Thus, what is needed is a comprehensive 

10 system that provides customers with simplified access 

to a telecommunications provider's products and 
services that they have subscribed. 

The assignee of the present invention has 
realized that the popularity of the public Internet 

15 provides a measure of platform independence for the 

customer, as the customer can run their own Internet 
web -browser and utilize their own platform connection 
to the Internet to enable service. This resolves many 
of the platform hardware and connectivity issues in the 

20 customers favor, and lets the customer choose their own 

platform and operating system. Web -based programs can 
minimize the need for training and support since they 
utilize existing client software which the user has 
already installed and already knows how to use, i.e., 

25 the browser. Further, if the customer later changes 

that platform, then, as soon as the new platform is 
Internet enabled, service is restored to the customer. 
The connectivity and communications software burden is 
thus resolved in favor of standard and readily 

30 available hardware and the browser and dial-up software 

used by the public Internet connection. 

An Internet delivered paradigm obviates many 
of the installation and configuration problems involved 
with initial setup and configuration of a customer 

35 workstation, since the custom application required to 

interface with the legacy system can be delivered via 
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the public Internet and run within a standard web- 
browser, reducing application compatibility issues to 
browser compatibility issues. 

The assignee of the present invention has 
5 also realized that the use of off-the-shelf web 

browsers by the customer significantly simplifies the 
enterprise burden by limiting the client development 
side to screen layouts and data presentation tools that 
use a common interface enabled by the web browser. 

10 Software development and support resources are thus 

available for the delivery of the enterprise legacy 
services and are not consumed by a need for customer 
support at the work station level. 

The assignee of the present invention has 

15 also realized that providing its management tools to 

its customers will develop customer loyalty, and more 
fully integrate the services provided by the 
telecommunications enterprise with the infrastructure 
of the customers organization. It is therefore highly 

20 desirable to provide these management tools over the 

public Internet. The public Internet provides access 
connectivity world wide via the TCP/IP protocol, 
without need to navigate various disparate security 
protocols, telephone exchanges, dialing standards or 

25 signal standards, thereby providing a measure of 

platform independence for the customer. 

Furthermore, an Intranet /Internet/Web- based 
reporting system provides a common GUI for the customer 
enabling both report requesting, customizing, 

30 scheduling and viewing of various types of data from 

different back-end telecommunications service and 
applications at a single point of customer contact. 

It is therefore desired to enable convenient 
customer access to an enterprise's management tools to 

35 facilitate the integration of the customer with the 

enterprise. This may be done by enabling access to the 
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enterprise's telecommunications network management 
services over the public Internet. The assignee of the 
present invention currently provides a number of 
independent legacy or host systems to provide customers 
5 with the following pertaining to their 

telecommunications networks: Priced Reporting 
(formerly Perspective) , for priced call data and 
reporting, and TrafficView for unpriced call detail 
data and reporting; Toll -Free Network Management (TFNM) 

10 (previously 800 Network Manager) , Call Manager, and 

Outbound Network Manager for command and control of 
network switching; BroadbandView, Broadband SNMP 
(previously HyperScope) and Event Monitor (previously 
Fault Manager) for network performance and alarm data; 

15 Service Inquiry (previously Direct Dispatch) for 

trouble ticket management; Real-Time Monitor for near 
real time call detail data; ClientView for invoice 
data. Limited interactive toll free network control is 
additionally supported whereby customers may change the 

20 configuration of their toll-free networks and "virtual" 

networks, i.e., Vnet networks. 

The present invention is directed to a 
Web-based system for doing business that utilizes 
an integrated customer interface system for 

25 telecommunications network management. The 

customer interface system is provided with a 
graphical user interface for enabling a user to 
interact with one or more telecommunications 
services provided by remote servers located in a 

30 telecommunications service provider's Intranet, and 

utilizes a Web. paradigm to allow an easy and 
convenient single point of access to all of the 
telecommunications services provided by the 
enterprise to the customer. While the present 

35 invention is useful for a wide range of commercial 

activity, ranging from a few thousand calls or 
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transactions a month to over a million per month, 
it is particularly desirable for activity ranging 
from 20,000 to 200,000 transactions or calls per 
month. 

5 In the preferred embodiment, the 

telecommunications products and services delivered 
to a client workstation having the integrated 
customer interface include: 

1) report requestor, report viewer, and 
10 report management applications enabling a customer 

to request, specify, customize and schedule 
delivery of reports pertaining to customer's real 
time "unpriced" call detail data and priced call 
detail data; 

15 2) centralized inbox system for providing on- 

line reporting, presentation, and notifications to a 
client workstation from one or more Intranet 
application services over an Internet/Intranet network; 

3) a real-time monitoring system enabling a 
20 customer to monitor call detail statistics and call 

detail data pertaining to their special service network 
usage, e.g., 800/8xx toll-free networks; 

4) a toll-free network management system 
enabling customers to define their own 800/8xx toll 

25 free number routing plans via the Web/Internet, 

enabling customers to change and modify their existing 
800/8xx toll free number routing plans, and, 
temporarily change the percent allocation of traffic 
for a particular 800/8xx toll free number based on 

30 certain criteria; 

5) an outbound network management system 
enabling customers to manage and track features and 
services associated with their virtual networks 
("Vnet") including management of calling party number 
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orders, dialing plan orders, calling card number 
management, and ID code sets orders; 

6) an event monitor system for providing 
customers with various reports and real-time alarm 
information relating to their switched- circuit (data 
and voice) networks in real time or near- real time, 
including: provision of physical and logical views of 
customers' Broadband data networks, physical and 
logical view of Broadband network alarms, and physical 
and logical performance information relating to the 
circuits which comprise a customer's Broadband data 
network, e.g., frame-relay, thus, allowing customers to 
make informed network management decisions in 
controlling their business telecommunications networks; 

7) a trouble ticket tool enabling a customer 
to open and monitor trouble tickets relating to network 
events on an enterprise network; 

8) a Web -based invoice reporting system 
allowing the customers access to their billing and 
invoice reports associated with network services 
provided to a customer; 

9) a web -based call manager service enabling 
call center customer's to control delivery of toll free 
calls from the telecommunications enterprise network to 
call centers, including call centers having multiple 
automatic call distributors (ACD's); 

10) an Internet "online" order entry and 
administration service to enable customers to manage 
their telecommunications accounts; and, 

11) a system for handling security and 
authentication requests from both client and server 
side of the applications implementing the suite of 
telecom products and services, and 

12) an on-line E-Billing electronic commerce 
tool that will allow selected networkMCI Interact 
customers to receive, analyze, and pay their invoice (s) 
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over the public Internet. On- Line E-billing features 
that includes electronic invoice presentment, invoice 
analysis and electronic bill payment, all from a single 
point of customer authentication. 

5 Integrated within the customer interface 

system is an application backplane unit for controlling 
and managing the overall user interface system to a 
number of Web enabled application services. By 
invoking the backplane unit a user may receive a number 

10 of disparate services available from the remote 

servers . 

Each remote telecommunications service 
provided includes its own user interface unit, referred 
to as a client application, independently implemented 

15 of one another and the backplane. Although the client 

applications are independently developed as separate 
modules, the interface of the present invention 
integrates the client applications into one unified 
system, allowing users to access the individual client 

20 applications via the backplane unit. Thus, the present 

invention provides interoperability between each of the 
client applications and the backplane, as well as among 
each of the client applications. 

Accordingly, the present invention provides 

25 an integrated customer interface and web -based delivery 

system for delivering to customers a number of telecom 
products and services available from remote servers, 
wherein separate client applications may communicate 
with one another and with the backplane unit. 

30 Thus, in accordance with the principles of 

the invention, there is provided an integrated system 
for conducting business over the Internet by providing 
one or more enterprise management tools to the 
enterprise customers, said management tools accessible 

35 from a client workstation employing a client browser 

associated with a customer and capable of receiving web 
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WO 99/15979 



PCT/US98/20I70 



pages from the enterprise which enable access to the 
enterprise management tools. This method of doing 
business is accomplished with one or more secure web 
servers which manage one or more secure client sessions 
over the Internet, each web server supporting secure 
communications with the client workstation; a web page 
backplane application capable of launching one or more 
management tool applications used by the enterprise. 
Each of the management tool applications provide a 
customer interface integrated within said web page 
which enables interactive Web/Internet based 
communications with the web servers; each web server 
supports communication of messages entered via the 
integrated customer interface to one or more remote 
enterprise management tool application servers which 
interact with the enterprise management tool 
applications to provide associated management 
capabilities to the customer. 

The messages include: 
i) requests for information pertaining to a 
customer's telecommunications business with the 
enterprise; or, 

ii) command and control directives for 
modifying a customer's telecommunications network 
assets; 

wherein a the remote telecommunications 
management tool application server processes said 
requests or directives and provides responses to said 
one or more web servers for secure downloading to the 
customer workstation for display via said integrated 
interface. 

Advantageously, this method of doing business 
obviates many of the installation and configuration 
problems involved with initial setup and configuration 
of a dial-up customer workstation, since the custom 
application required to interface with the legacy 
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system can be delivered via the public Internet and run 
within a standard web -browser, reducing application 
compatibility issues to browser compatibility issues. 

The present invention further enables access 
to legacy management tools used by enterprise 
management in the conduct of the enterprise business to 
the enterprise customer, to enable the customer to more 
effectively manage the business conducted by the 
customer through the enterprise, this access being 
provided over the public Internet* 

The present invention provides a single point 
of access for the customer to open a plurality of 
disparate enterprise management tools, and to allow the 
customer to thereafter modify their own authorization 
and entitlements to these management tools, and be 
automatically billed for the changes they have 
requested. 

The present invention also provides an 
integrated E-Billing system for doing business in which 
customers may view unpriced and priced 
telecommunication call data, to view electronically 
generated invoices for the telecommunication service 
provided, and to pay for these services with an E- 
Billing electronic fund transfer. 

The present invention also uses the Internet 
to deliver additional value for networkMCI One 
customers and to leverage the web technology of the 
present invention by giving customers the option of 
receiving, analyzing, and paying their networkMCI One 
invoice over the public Internet. The present 
invention provides an "intelligent, navigable invoice" 
where customers and users can drill down from summary 
level information to specific site and service level 
detail . 

This invention further provides enterprise - 
wide customer operations via the Internet and create a 
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cost-effective, 24 hour a day, 7 day a week virtual 
communications center for the enterprise customers, 
thereby providing a competitive advantages for business 
users of the invention. Using the present invention, 
customers can easily and conveniently manage 
enterprise -wide and individual telecom services - 
anywhere, anytime and online. Whether the customer has 
dedicated lines or dial access lines, command and 
control of critical telecom functions is only a mouse- 
click away. This provides a substantial cost and time 
savings to the customer of the enterprise. 

The present invention provides a suite of 
Web -based communications management tools that enable 
customers to monitor, analyze and redirect voice, data 
and Internet resources. The invention provides new 
command and control tools for enterprise -wide and 
personal communications include: traffic monitoring and 
reporting and service configuration, electronic billing 
and reporting, universal messaging, order entry and 
provisioning, product and service training, and 
customer care. 

Further, the present invention defines a new 
business model by utilizing the Internet as a medium 
for operating and managing mission- critical 
communications operations, by creating a more 
convenient way for customers to order, provision, 
monitor, report, purchase and pay for their services. 

Still further, the present invention stream- 
lines the enterprise front-and back-office processes to 
more effectively serve customers of the enterprise. 
Because customers have the option to self -serve their 
business functions online, the enterprise sales 
resources are able to play a more consultative role and 
respond to communications conditions that require more 
complex management. 
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The present invention integrates the tools 
and resources from the enterprises core long distance, 
local, data, Internet, call center and global 
businesses. This approach leverages the enterprises 
Internet expertise, harnesses the power of the 
enterprise intelligent network, and utilizes the 
enterprises unique integration capabilities - at the 
network, billing, product and service levels - for the 
benefit of its customers as well as the enterprise. 

The components of the present invention 
include: Traffic Monitoring and Reporting - as part of 
networkMCI Interact, customers can monitor and route 
long distance, local, data and Internet traffic, 
including service configuration and setting event 
alarms; universal Messaging - integrated messaging; 
allows users to maintain personal profiles under the 
networkMCI Contact service; Order Entry and 
Provisioning - wherein customers can order new products 
online and provision services online; Customer Care - 
online support for MCI product and services, utilizing 
networkMCI Click 1 nConnect, Web Callback, E-mail support 
and Service Inquiry, Click 1 nConnect being a service 
that allows Web -users to make a PC -to -phone connection 
over the Internet; E- Billing and Reporting, which 
allows customers to receive electronic invoices and 
reports, to remit payment electronically; and to 
provide custom views analysis of billing records; 
networkMCI BroadbandView, a Web-based traffic and 
reporting tool for data customers will be integrated 
under the Interact traffic monitoring and reporting 
portfolio; and networkMCI Contact, a service that 
allows end-users to manage their paging, E-mail, voice 
mail and fax as part of the personal profiles 
management component of the present invention. 

By utilizing the present invention, customers 
are able to react to emergency situations quickly. For 
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example, a telecom director - responsible for managing 
enterprise -wide communications for a packaged goods 
company - receives an 'alarm 1 on his pager at 11 
o'clock at night, A snowstorm in the Northeast has 
5 paralyzed the city where the company operates a 24 hour 

a day x 7 days a week call center. The telecom 
director powers up his laptop computer from home logs 
on to the MCI Web site, enters his authentication 
passcode for security and with several clicks of a 

10 mouse, reroutes traffic to the company's call center in 

Phoenix. For the next 36 hours, he is able to monitor 
the call routing situation via the Web site in real- 
time, and when the snow clears, he routes the traffic 
back to the Northeast center. 

15 In a second example, a communications manager 

working for a U.S. -based software company, is 
responsible for the telecom needs of 50 offices 
worldwide. The manager is responsible for sorting and 
tracking expenses for all 50 locations and for all the 

20 company's services. The paper invoices can sometimes 

exceed hundreds of pages. With electronic billing the 
manager will no longer have to wait to receive a paper 
invoice in the mail. Instead, real-time e-bills will 
be available on a secure web site, with the ability to 

25 manipulate and view the data in many different formats 

- by service, by location, etc. After review, the 
manager is able to remit invoices electronically. 

The present invention uses Java technology to 
optimize computing resources and network bandwidth and 

30 deliver information to the user desktop quickly and 

efficiently. An enterprise customers is able to access 
the same up-to-date information from a dial-up 
connection at his or her home that would be available 
via a dedicated LAN /WAN environment at their office, 

35 independent of their operating systems. Intelligent 

authentication provides security as well as custom 
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information that is delivered to a customer's 
personalized Webtop - eliminating the need for 
customers to cut through clutter to find the 
information needed. 

Further features and advantages of the 
invention will become more readily apparent from a 
consideration of the following detailed description set 
forth with reference to the accompanying drawings, 
which specify and show preferred embodiments of the 
invention, wherein like elements are designated by, 
identical references throughout the drawings; and in 
which: 

Figure 1 illustrates the software 
architecture component comprising a three- tiered 
structure; 

Figure 2 is a diagrammatic overview of the 
software architecture of the networkMCI Interact 
system; 

Figure 3 is an illustrative example of a 

backplane architecture schematic- 
Figure 4 depicts the logon process for the 

nMCI Interact system; 

Figures 5(a) and 5(b) illustrate example nMCI 

Interact system web home pages presenting customer - 

selectable telecommunications network services in which 

the client/customer is entitled; 

Figure 6 is a flow diagram illustrating the 

backplane logic process when a user selects a service; 
Figure 7 illustrates an architectural 

overview of the StarOE order entry component of the 

NMCI Interact system; 

Figure 7 (a) is a diagram depicting the 

execution of a transaction by the Service Inquiry 

application server with each bubble representing a 

separate thread. 
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Figure 8 is an input process flow diagram, 
illustrating inputs to the StarOE order entry component 
of the NMCI Interact system; 

Figure 9 is an output process flow diagram, 
5 illustrating outputs from the StarOE order entry 

component of the NMCI Interact system; 

Figure 10 is a block diagram depicting the 
physical architecture of the StarWRS component of 
networkMCI Interact Reporting system; 
10 Figures 11(a) - 11(c) illustrate flow 

diagrams depicting the report request/scheduling 
Process 600 implemented by StarWRS Report Manager and 
Report Requestor tools of the invention; 

Figures 12 (a) -12(h) illustrate various 
15 examples of report requestor screen dialogs enabling 

user customization of report requests. 

Figure 13 (a) illustrates an example browser 
based message center screen dialog; 

Figure 13 (b) illustrates an example report 
20 viewer dialog box used for requesting view of available 

generated reports; 

Figure 14 (a) illustrates the primary 
components implemented in the StarODS priced reporting 
component 400; 

25 Figure 14 (b) depicts generally the process 

performed by the DSS in fulfilling a priced reporting 
request received from StarWRS; 

Figures 15(a) -15(c) illustrate the end-to-end 
process 600 for fulfilling priced call detail data 
30 report request; 

Figure 16 illustrates an example screen 
display when the StarOE application is launched; 

Figure 17 is a sample StarOE screen 1540 for 
adding and modifying reporting options which are used 
35 by the StarWRS; 
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Figure 18 illustrates the unpriced call 
detail reporting and real-time traffic monitoring 
component 500 for NMCI Interact system; 

Figure 19 is an general flow diagram of the 
process by which the TVS server 550 gets data. 

Figure 20 is a detailed flow diagram 
depicting the internal TVS server processes for 
receiving customer TVS enablement data from order entry 
and CORE systems; 

Figure 21 is a high-level diagram depicting 
TCR data flow between processes internal to the TVS 
server; 

Figure 22 is a high-level flow diagram 
depicting TVS unpriced call detail data report 
generation process; 

Figures 23 (a) -23(b) illustrate flow charts 
describing the real-time monitoring process of the 
invention. 

Figure 24 illustrates the Particular 
methodology employed for periodically updating a Web 
page with updated statistical data. 

Figure 25(a) illustrates the high-level 
design of the Service Inquiry application 2200; 

Figure 25(b) illustrates the Service Inquiry 
application Server 2300 interfacing with the Legacy 
Backend 40(a), CSM/SI through Requestor and Receiver 
objects; 

Figures 25(c) -25(1) illustrate examples of SI 
application dialog windows enabling user creation and 
querying of trouble tickets; 

Figure 25 (m) illustrates domain object model 
(DOM) 2600 implemented in Service Inquiry; 

Figure 26 is a general block diagram 
depicting the physical architecture of the TFNM system 
components; 
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Figures 27 (a) -27(c) illustrate exemplary- 
screens providing TFNM functionality through option 
menus ; 

Figure 27(d) illustrates an example display 
when the File/Select Corp ID menu option of Figure 
27 (a) is selected; 

Figure 27(e) illustrates an exemplar screen 
display depicting a hierarchical tree view of an 
example toll-free number routing plan; 

Figure 27(f) illustrates an example IMPL 
dialog screen enabling the user to generate a TEMP 
IMPL/IMPL order for a desired Corp Id; 

Figure 27(g) illustrates an example QUIK 
dialog screen enabling the user to generate a TEMP 
QUIK/QUIK order for a desired Corp Id; 

Figure 27(h) illustrates an exemplar screen 
display showing the results of an order query; 

Figure 27 (i) illustrates an exemplary screen 
display showing the options for changing existing 
network plan routing orders. 

Figure 28 is a block diagram depicting the 
physical architecture of the ONM system 200 of the 
invention; 

Figures 29 (a) -29 (P) illustrate various 
examples of ONM web page screen dialogs enabling user 
interaction with Outbound Network management system. 

Figure 30 is a detailed block diagram 
depicting the physical architecture of the Broadband 
reporting system component of the present invention; 

Figure 31 illustrates those components 
utilized for Broadband performance reporting; 

Figures 32 (a) -32(b) illustrate the flow 
diagrams depicting the Broadband system report creation 
process 3 00; 
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Figure 33 illustrates a process flow diagram 
depicting various Broadband reporting data retrieval 
process; 

Figures 34(a) - 34(g) depict example graphic 
reports relating to a customers Frame Relay 
( Broadband ) network ; 

Figures 35 (a) -35(b) illustrate two example 
views presented by the Broadband map viewer; 

Figure 36 is a block diagram illustrating an 
overview of the event monitor component of the NMCI 
Interact System; 

Figure 37 illustrates an example of a back- 
end configuration for the fault management system; 

Figure 3 8 illustrates an architectural view 
of a fault management host; 

Figure 39 is a high level logic flowchart 
depicting the operation of the event monitor component 
of the NMCI Interact System; 

Figure 40 illustrates a high level overview 
of the call manager system environment; 

Figure 41 illustrates call manager webstation 
component architecture of the nMCI Interact system, 
showing interconnections among the components; 

Figure 42 illustrates the objects making up 
the client interface code, in one embodiment of the 
call manager system; 

Figure 43 illustrates one embodiment of the 
software architecture showing communications between 
the client 20 and the call manager web server 1132 and 
its components; 

Figure 44 illustrates an example of call 
manager webstation application physical architecture 
when one or more call manager web servers 1132 bypass 
the CMIDS component 1140; 
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Figure 45 is an example of a CMIDS conceptual 
model 1140 providing details of the CMIDS software 
components ; 

Figure 46 illustrates a back-end process flow 
5 for the call manager system component of the present 

invention; 

Figure 47 illustrates an application- level 
process flow 1250 for the call manager system component 
of the. present invention; 
10 Figure 48 illustrates an example of a call 

manager webstation application screen including the 
toolbar and the route writing palette; 

Figure 49 shows an example of a system status 

display; 

15 Figure 50 illustrates an example of a ACD 

collector administration function screen displayed for 
providing the user with the ability to view, create, 
delete and edit ACD collectors; 

Figure 51 illustrates an architectural 
20 schematic of the online invoicing system 1300 component 

of NMCI Interact; 

Figure 52 is a flow diagram illustrating an 
online invoicing process flow; 

Figure 53(a) is a sample criteria screen 
25 launched from the NMCI Interact home page; 

Figure 53 (b) is a sample screen displaying a 
list of invoice reports; 

Figure 54 is a sample screen displaying an 
invoice document generated by the online invoicing 
30 system component of the invention; 

Figure 55 is a flow diagram illustrating an 
online invoicing back-end server process flow 1400 
during document indexing and storing; 

Figure 56 is a flow diagram illustrating an 
35 online invoicing back-end server process flow when 
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responding to client requests for document 
presentation; 

Figure 57 is a schematic illustration of the 
message format passed from the user workstation 20 to 
the secure web server 24 over the public internet; 

Figure 58 is a data flow diagram illustrating 
the present invention's process flow during logon, 
entitlement request/response, heartbeat transmissions 
and logoff procedures; and 

Figure 59 is a data flow diagram for various 
transactions communicated in the system of the present 
invention. 

Figure 60 is a diagram depicting the physical 
network architecture of the NMCI Interact system of the 
present invention ; 

Figures 61(a) is a schematic illustration 
showing the message format passed between the 
Dispatcher server and the application specific proxy. 

Figures 61(b) is a schematic illustration of 
the message format passed between the application 
specific proxy back to the Dispatcher server. 

The present invention is a Web -based, 
telecommunications network application delivery system 
for delivering an integrated suite of customer network 
management tools to customers of telecommunications 
service providers using a Web browser paradigm. The 
integrated suite of customer network management tools 
described herein and provided by the assignee of the 
present invention, is collectively referred to as the 
networkMCI Interact system ("NMCI Interact") . Such an 
integrated suite of Web -based interactive applications 
provides all of the tools necessary to enable customers 
to manage their telecommunication assets, quickly and 
securely, from anywhere in the world. 

The NMCI Interact system architecture is 
basically organized as a set of common components 
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comprising the following: 

1) a software architecture detailing the 
client and server based aspect of NMCI Interact; 

2) a network architecture defining the 

5 physical network needed to satisfy the security and 

data volume requirements of the networkMCI System; 

3) a data architecture detailing the back- 
end or data sources for the networkMCI reporting 
system; and 

10 4) an infrastructure covering security, 

order entry, fulfillment, billing, self -monitoring, 
metrics and support. Each of these common component 
areas will be discussed in further detail herein. 

Figure 1 is a diagrammatic illustration of 

15 the software architecture in which the present 

invention functions. A first tier of software services 
are resident on a customer work station 20 and provides 
customer access to the enterprise system, having one or 
more downloadable application objects 10 directed to 

20 front end business logic and application services, a 

backplane service layer 12 for managing sessions, one 
or more presentation services objects for the 
presentation of telecom network management options and 
customer requested telecommunications network 

25 management data in a browser recognizable format, and a 

customer supplied browser for presentation of customer 
options and data to the customer and for internet 
communications over the public Internet. 

A second or middle tier 16 is provided, 

30 having secure web servers and back end services to 

provide applications that establish user sessions, 
govern user authentication and their entitlements, and 
communicate with adaptor programs to simplify the 
interchange of data across the network. 

35 A back end or third tier 18 having 

applications directed to legacy back end services 
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includes database storage and retrieval systems and one 
or more database servers for accessing system resources 
from one or more legacy systems. 

Generally, the customer or client tier or 
workstation 20 is client software capable of providing 
a platform- independent, browser -based, consistent user 
interface implementing objects programmed to provide a 
reusable and common GUI abstraction and problem- domain 
abstractions. More specifically, the client- tier 
software is created and distributed as a set of Java 
classes including the applet classes to provide an 
industrial strength, object-oriented environment over 
the Internet. Application - specific classes are 
designed to support the functionality and server 
interfaces for each application with the functionality 
delivered through the system being of two -types: 
1) cross-product, for example, inbox and reporting 
functions, and 2) product specific, for example, 
Service Inquiry, Toll Free Network Management ("TFNM") 
or Call Manager ("CM") functions. The system is 
capable of delivering to customers the functionality 
appropriate to their product mix. 

Figure 2 is a diagrammatic illustration of 
the network and platform components of the NMCI 
Interacts system, including: the Customer workstation 
20; the Demilitarized Zone 17 (DMZ) ; Web Servers 
cluster 24; the MCI Intranet Dispatcher/Proxy Servers 
cluster 30; and the MCI Intranet Application servers 
40, warehouses, legacy systems, etc. 

The customer workstation 20 is browser 
enabled and includes client applications responsible 
for presentation and front -end services. Its functions 
include providing a user interface to various MCI 
services and supporting communications with MCI f s 
Intranet web server cluster 24. As illustrated in 
Figure 2, the client tier software is responsible for 
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presentation services to the customer and generally 
includes a web browser 14 and additional object 
oriented programs residing in the client workstation 
platform 20. The client software is generally 
organized into a component architecture with each 
component generally comprising a specific application, 
providing an area of functionality. The applications 
generally are integrated using a "backplane" services 
layer 12 which provides a set of services to the 
application objects which provide the front end 
business logic and manages their launch. 

As will be described, each of the NMCI 
Internet suite of network management applications 
implements a set of common objects (CO) that minimizes 
the replication of code, and provides a framework in 
which a family of internet applications may be managed 
and created including: communications, I/O services to 
local resources, user authentication, 

internationalization, common look and feel, application 
management, and a model view controller (MVC) 
framework. The primary common object services for each 
of the suite of applications include: graphical user 
interface (GUI); application launch; window navigation 
among applications; interapplication communications; 
printing; user identity, session management, 
authentication, and entitlements; data import and 
export; logging and statistics; error handling; version 
management; and messaging services. 

As shown in Figure 2, the aforesaid objects 
communicate data by establishing a secure TCP messaging 
session with one of the DMZ networkMCI Interact Web 
servers 24 via an Internet secure communications path 
22 established, preferably, with a secure sockets SSL 
version of HTTPS. The DMZ networkMCI Interact Web 
servers 24 function to decrypt the client message, 
preferably via the SSL implementation, and unwrap the 
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session key and verify the users session. After 
establishing that the request has come from a valid 
user and mapping the request to its associated session, 
the DMZ Web servers 24 will re -encrypt the request 
using symmetric encryption and forward it over a second 
secure socket connection 23 to the dispatch server 26 
inside the enterprise Intranet. 

As will be hereinafter described in greater 
detail, a networkMCI Interact session is designated by 
a logon, successful authentication, followed by use of 
server resources, and logoff. However, the world-wide 
web communications protocol uses HTTP, a stateless 
protocol, each HTTP request and reply is a separate 
TCP/IP connection, completely independent of all 
previous or future connections between the same server 
and client. The present invention is implemented with 
a secure version of HTTP such as S-HTTP or HTTPS, and 
preferably utilizes the SSL implementation of HTTPS. 
The preferred embodiment uses SSL which provides a 
cipher spec message which provides server 
authentication during a session. The preferred 
embodiment further associates a given HTTPS request 
with a logical session which is initiated and tracked 
by a "cookie jar server" 32 to generate a "cookie" 
which is a unique server -generated key that is sent to 
the client along with each reply to a HTTPS request. 
The client holds the cookie and returns it to the 
server as part of each subsequent HTTPS request. As 
desired, either the Web servers 24, the cookie jar 
server 32 or the Dispatch Server 26, may maintain the 
"cookie jar" to map these keys to the associated 
session. A separate cookie jar server 32, as 
illustrated in Figure 2 has been found desirable to 
minimize the load on the dispatch server 26. A new 
cookie will be generated when the response to the HTTPS 
request is sent to the client. This form of session 
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management also functions as an authentication of each 
HTTPS request, adding an additional level of security 
to the overall process. 

As illustrated in Figure 2, after one of the 
DMZ Web servers 24 decrypts and verifies the user 
session, it forwards the message through a firewall 25b 
over a TCP/IP connection 23 to the dispatch server 26 
on a new TCP socket while the original socket 22 from 
the browser is blocking, waiting for. a response. The 
dispatch server 26 will unwrap an outer protocol layer 
of the message from the DMZ services cluster 24, and 
will reencrypt the message with symmetric encryption 
and forward the message to an appropriate application 
proxy via a third TCP/IP socket 27. While waiting for 
the proxy response all three of the sockets 22, 23, 27 
will be blocking on a receive. 

Specifically, once the message is decrypted, 
the wrappers are examined to reveal the user and the 
target middle- tier (Intranet application) service for 
the request. A first -level validation is performed, 
making sure that the user is entitled to communicate 
with the desired service. The user's entitlements in 
this regard are fetched by the dispatch server 26 from 
StarOE server 39 at logon time and cached. 

If the requestor is authorized to communicate 
with the target service, the message is forwarded to 
the desired service's proxy. Each application proxy is 
an application specific daemon which resides on a 
specific Intranet server, shown in Figure 2 as a suite 
of mid- range servers 30. Each Intranet application 
server of suite 30 is generally responsible for 
providing a specific back-end service requested by the 
client, and, is additionally capable of requesting 
services from other Intranet application servers by 
communicating to the specific proxy associated with 
that other application server. Thus, an application 
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server not only can offer its browser a client to 
server interface through the proxy, but also may offer 
all its services from its proxy to other application 
servers. In effect, the application servers requesting 
5 service are acting as clients to the application 

servers providing the service. Such mechanism 
increases the security of the overall system as well as 
reducing the number of interfaces. 

The network architecture of Figure 2 may also 

10 include a variety of application specific proxies 

having associated Intranet application servers 
including: a StarOE proxy for the StarOE application 
server 39 for handling authentication order 
entry/billing; an Inbox proxy for the Inbox application 

15 server 31, which functions as a container for completed 

reports, call detail data and marketing news messages, 
a Report Manager Proxy capable of communicating with a 
system- specif ic Report Manager server 32 for 
generating, managing and scheduling the transmission of 

20 customized reports including, for example: call usage 

analysis information provided from the StarODS server 
33; network traffic analysis/monitor information 
provided from the Traffic view server 34; virtual data 
network alarms and performance reports provided by 

25 Broadband server 35; trouble tickets for switching, 

transmission and traffic faults provided by Service 
Inquiry server 36; and toll free routing information 
provided by Toll Free Network Manager server 37. 

As partially shown in Figure 2, it is 

30 understood that each Intranet server of suite 30 

communicates with one or several consolidated network 
databases which include each customer's network 
management information and data. In the present 
invention the Services Inquiry server 3 6 includes 

35 communication with MCI's Customer Service Management 

legacy platform 40(a). Such network management and 
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customer network data is additionally accessible by 
authorized MCI management personnel. As shown in 
Figure 2, other legacy platforms 40(b), 40(c) and 40(d) 
may also communicate individually with the Intranet 
servers for servicing specific transactions initiated 
at the client browser. The illustrated legacy 
platforms 40 (a) -(d) are illustrative only and 
it is understood other legacy platforms may be 
integrated into the network architecture illustrated in 
Figure 2 through an intermediate midrange server 30. 

Each of the individual proxies may be 
maintained on the dispatch server 26, the related 
application server, or a separate proxy server situated 
between the dispatch server 26 and the midrange server 
30. The relevant proxy waits for requests from an 
application client running on the customer's 
workstation 20 and then services the request, either by 
handling them internally or forwarding them to its 
associated Intranet application server 30. The proxies 
additionally receive appropriate responses back from an 
Intranet application server 30. Any data returned from 
the Intranet application server 30 is translated back 
to client format, and returned over the internet to the 
client workstation 20 via the Dispatch Server 26 and at 
one of the web servers in the DMZ Services cluster 24 
and a secure sockets connection. When the resultant 
response header and trailing application specific data 
are sent back to the client browser from the proxy, the 
messages will cascade all the way back to the browser 
14 in real time, limited only by the transmission 
latency speed of the network. 

The networkMCI Interact middle tier software 
includes a communications component offering three (3) 
types of data transport mechanisms: 1) Synchronous 
which is used for situations in which data will be 
returned by the application server 30 quickly; 2) 
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Asynchronous which is used for situations in which 
there may be a long delay in application server 30 
response; and 3) Bulk transfer which is used for large 
data transfers. 

The DMZ Web servers 24 are found in a special 
secure network area set aside from the Intranet to 
prevent potentially hostile customer access. All DMZ 
equipment is physically isolated and firewalled as 
illustrated at 25(a), 25(b) from the company Intranet. 
Similarly, the DMZ equipment is firewalled and obscured 
from hostile attacks from the public Internet, except 
for limited web browser access to the web servers which 
are located in the DMZ . The customer's web browser 
connects to a web server in the DMZ which in turn 
connects to the Dispatcher server 26 which acts as a 
proxy to extract select information from the midrange 
servers 30. A user may not directly connect to any 
enterprise server in the enterprise intranet, thus 
ensuring internal company system security and 
integrity. 

The DMZ also isolates the company Intranet 
from the public Internet because the web servers 24 
located in the DMZ never store or compute actual 
customer sensitive data. The web servers only put the 
data into a form suitable for display by the customers 
web browser. Since the DMZ web servers 24 do not store 
customer data, there is a much smaller chance of any 
customer information being jeopardized in case of a 
security breach. 

Client browser application 

As mentioned, one component of the nMCI 
Interact system is the client- tier software component 
which provides the integrated and unified interface to 
each of the telecommunications network management 
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services available to a user. As shown in Figure 3, 
the system of the present invention implements an 
"application backplane" 12, a single object which keeps 
track of al the client applications, and which has 
capabilities to start, stop, and provide references to 
any one of the client applications. The application 
backplane 12 is typically implemented as a Java applet 
and is launched when a Web page is retrieved via URL 
pointing to the enterprises Web site. The client 
applications typically comprise of graphical user 
interface programs which enable a user to interact with 
one or more Web enabled remote services. 

The backplane 12 and the client applications 
use a browser 14 such as the Microsoft Explorer 
versions 4.0.1 or higher for an access and distribution 
mechanism. Although the backplane is initiated with a 
browser 14, the client applications are generally 
isolated from the browser in that they typically 
present their user interfaces in a separate frame, 
rather than sitting inside a Web page. 

The backplane architecture is implemented 
with several primary classes. These classes include 
COBackPlane, COApp, COAppImpl, COParm, and COAppFrame 
classes. COBackPlane 12 is an application backplane 
which launches the applications 54a, 54b, typically 
implemented as COApp. COBackPlane 12 is generally 
implemented as a Java applet and is launched by the Web 
browser 14. This backplane applet is responsible for 
launching and closing the COApps . 

When the backplane is implemented as an 
applet, it overrides standard Applet methods initO, 
start (), stopO and run() . In the initO method, the 
backplane applet obtains a COUser user context object. 
The COUser object holds information such as user 
profile, applications and their entitlements. The 
user's configuration and application entitlements 
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provided in the COUser context are used to construct 
the application toolbar and Inbox applications. When 
an application toolbar icon is clicked, a particular 
COApp is launched by launchAppO method. The launched 
application then may use the backplane for inter - 
application communications, including retrieving Inbox 
data. 

The. COBackPlane 12 includes methods for 
providing a reference to a particular COApp, for 
interoperation. For example, the COBackPlane class 
provides a getApp method which returns references to 
application objects by name. Once, retrieved in this 
manner, the application object's public interface may 
be used directly. 

COApp is the base interface for the 
applications. The applications, e.g., Service Inquiry 
54a or Call Manager 54b, generally have their startup 
code and inter- application interface in a class which 
implements COApp. Generally, two classes are available 
for the applications, COAppImpl or COApplet. 
Alternatively, they may provide their own 
implementation of the interface. In the preferred 
embodiment, applications typically extend COAppImpl. 

COAppImpl is an "applet- like" class, but it 
does not derive from java. applet .Applet nor from 
java.awt. Panel. By not deriving from Applet, the 
applications may be launched at any time without 
browser having to be pointed to specific page, and 
frees the applications from running within the browser 
frame. Classes derived from COAppImpl are created, 
launched, stopped, and destroyed by the COBackPlane 12. 
This provides a tight and controlled integration by the 
system of the present invention. 

The COApplet class, on the other hand, 
extends the Applet class and is intended to be launched 
by the browser from an HTML <Applet> tag. Extension 
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from Applet is provided for applications needing more 
isolation from the present integrated system, or 
requiring a separate browser -based display space. The 
COApplet class implements most of the COApp interface 
by forwarding it to a contained COApp Impl object. 

COAppFrame 56a, 56b is a desktop window 
created and used by a COApp to contain its user 
interface. The COAppFrame 56a, 56b is a separate 
window from the Web browser 50. Generally, the 
COAppFrame 56a, 56b has a menu, toolbar, and status 
bar. The COAppFrame 1 s attachToViewArea () method may be 
used to paste a COView object 60a, 60b, 60c into a 
COAppFrame 56a, 56b. The COView class is an extension 
of java. awt. Panel . It provides a general purpose 
display space and container for an applications visual 
representation. Application classes typically extend 
the COView class to implement their presentation logic. 
COApp may use none, one, or many COAppFrames 56a, 56b. 

COParm is a generic data class used to pass 
parameters between applications. COApp interface 
provides a public method for passing COParm message 
objects, for example, public void processMessage 
(COParm message) , which may be used to pass messages 
between applications. The COParm class contains a set 
of name -value pairs which are used to present 
information or requests. 

Logon 

As illustrated in Figure 4, a logon process 
for the NMCI Interact 1 s integrated customer interface 
of the present invention starts with the browser launch 
as indicated at step 60, and the entry of the 
enterprise URL, such as HTTPS : //www. enterprise.com, as 
indicated at step 62. Following a successful 
connection, an SSL handshake protocol may be initiated 
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at this point as indicated at step 63. As will be 
explained in greater detail herein, when a SSL client 
and server first start communicating, they agree on a 
protocol version, select cryptographic algorithms, 
authenticate the server (or optionally authenticate 
each other) and use public -key encryption techniques to 
generate shared secrets. 

After successful SSL handshake at step 63, an 
HTML- file invoking and an associated logon applet is 
downloaded with software tools and common objects in 
steps 64, 66, to present a web page including name and 
password entry fields for user to enter. The user is 
then prompted to enter name and password on the Web 
page. If the NMCI Interact system determines that the 
software files including classes for initiating a 
session, have been already downloaded, for example, 
from a previous session, the steps 62, 64, 66 are 
skipped . 

The logon applet checks for the name/password 
entry and instantiates a session object in step 72, 
communicating the name/password pair. The session 
object sends a message containing the name/password to 
a remote server for user validation in step 74. When 
the user is properly authenticated by the server in 
step 76, another Web page having backplane object is 
downloaded in steps 78, 80, 84. This page is referred 
to as a home page. At the same time, all the 
application software objects are downloaded in step 82. 
If the system of the present invention determines that 
the backplane and application files have been already 
downloaded, the steps 80, 82, 84 are not performed. 
The backplane object is then instantiated in step 86. 

As will be explained, the backplane 
communicates with a remote order entry server component 
("StarOE") server 39 (Figure 2) to retrieve the user's 
entitlements in step 88. The entitlements represent 
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specific services the user has subscribed and has 
privilege to access. It also describes what 
entitlements the user may have within any single 
service. For example, from the COUser context, the 
backplane can obtain the list of applications that the 
user is entitled to access. In addition, each COApp 
holds set of entitlements within that application in 
COAppEntitlements object. 

Using the information from the COUser 
context, the backplane knows which COApps to provide, 
e.g., which buttons to install in its toolbar. The 
backplane stores the user specific entitlements in 
memory for other processes to access. After 
determining the entitlements, the backplane initiates a 
new thread and starts an application toolbar in step 
90. The application toolbar includes the remote 
services to which the user has subscribed and may 
select to run. From the application toolbar, a user is 
able to select a service to run. Upon user selection, 
the selection is communicated from the application 
toolbar to the backplane in steps 92, 94, which then 
launches the graphical user interface program 
associated with the selected service. The application 
toolbar remains on the user display, even after a 
particular service has been initiated. This is useful 
when a user desires to start up another remote service 
directly from having, run a previous service because 
the user then need not retrieve the home page again. 

If it is determined that the user entered 
password is not valid in step 70 or step 76, an 
attempted logon count is incremented in step 96. If 
the user's attempted logon count is greater than a 
predefined allowed number of tries as indicated in step 
98, a message is conveyed to the user in step 101 and 
the user must restart the browser. If the user's 
attempt to log count is not greater than the predefined 
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allowed number of tries, a "failed login" message is 
conveyed to the user in step 102, and the user is 
prompted to reenter name/password in step 68. If it is 
determined that the user password has expired, the user 
is prompted to change the password in step 104. For 
example, the user may be required to change the 
password every 30 days for security reasons whenever 
the user changes the password, the new password is 
transmitted in real time to a server responsible for 
updating and keeping the password entry for the user. 
The user than enters the new password in step 104 and 
continues with the processing described above in step 
70. 

An illustrative example of the nMCI Interact 
logon Web page typically includes a name field and a 
password field for the user to enter. After the user 
is properly authenticated via the logon page, the nMCI 
Interact home page is retrieved. 

Figures 5 (a) and 5 (b) illustrate example nMCI 
Interact home pages, i.e., a Web page having the 
backplane object 12. The home page 79(a) is downloaded 
after the authentication via a logon page and provides, 
for example, a suite 95 of network management 
reporting, applications including: MCI Traffic Monitor 
application 85; an alarm monitor application 87; a 
Network Manager application 89 and the Service Inquiry 
application 91. Access to network functionality is 
also provided through Report Requestor 83, which 
provides a variety of detailed reports for the 
client/customer and a Message Center 77 for providing 
enhancements and functionality to traditional e-mail 
communications. An application toolbar 71 is also 
provided that is different from the icons 95 in that 
the application tool bar remains on a screen, even when 
the home page 79(a) is no longer displayed. The home 
page also typically comprises HTML links to other 
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services 96, These services may be new information 
center, features benefits, or support center for the 
system of the present invention. 

Backplane Logic 

Figure 6 is a flow diagram illustrating the 
backplane logic process when a user selects a service 
from a home page or the application toolbar. The user 
initially selects an application in step 110. If the 
selected application is derived from COAppImpl, the 
COBackPlane object 12 instantiates the desired 
application object by name. The COBackPlane 12 also 
creates a COAppStartThread object to manage the startup 
of the COAppImpl in step 116. Each COAppImpl is 
started in it's own thread. COAppStartThread calls the 
COAppImpl 1 s initO method. Here the COAppImpl 
typically creates the application- specif ic classes it 
needs, including a COAppFrame (or a derived class 
thereof) if desired. COAppStartThread calls the 
COApp's start () method. Once the start () method has 
completed, the COAppStartThread ends. 

If the desired application is derived from 
java. applet .Applet, a new browser window is created, 
and directed to the HTML page from which the applet to 
be loaded 338. This will cause the browser to load the 
applet, and call its initO and start () method. In its 
initO method, the applet obtains a reference to the 
backplane by calling the static method of the 
COBackPlane class getBackPlane ( ) . Also in its initO 
method, the applet notifies the backplane that it has 
been launched by calling the backplane's registerApp ( ) 
method. Alternatively, if the desired application is 
an application requiring a direct URL launch from the 
home page, for example RTM as shown at step 112, the 
desired application is invoked by retrieving a Web page 
having the application's URL as shown at step 118. 
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Each application gets a session identifier in 
step 120 upon its startup. Should the applications 
desire to perform some further authentication, they are 
free to retrieve the COUser object, and perform 
5 whatever special authentication the need, without 

troubling the user to re-enter his/her username and 
password. During the processing of functions specific 
to each application, the applications are able to 
communicate with one another as well as with the 

10 backplane by getting a reference to the applications or 

the backplane and invoking the public interfaces or 
methods with the reference. 

After a user is finished with interacting 
with COApp, the user requests the selected COApp to 

15 exit via a menu selection, clicking on a close box 

button on a window frame, or a keyboard command, for 
example. The COApp then requests exit from the 
COBackPlane. If the selected application is derived 
from COAppImpl, the COBackPlane creates a 

20 COAppStopThread to manage the exit of the COApp. As 

with startup, each COApp is stopped in its own thread. 
COAppStopThread calls COApp' s stopO method. Typically 
a COApp would not override this method. It is called 
for consistency with the applet interface of the COApp 

25 class. An applet's stopO method is called by the Web 

browser when the web browser leaves the page from which 
the applet was loaded, in order to allow the applet to, 
for instance, stop an animation. For consistency with 
this model, COApps may use this method to stop long- 

30 running threads. COAppStartThread calls COApp' s 

destroy () method. Here the COApp typically performs 
resource cleanup routines, including stopping any 
threads, and calling the dispose () method for any 
COAppFrame objects. 

35 If the selected application is derived from 

java. applet .Applet , the Web browser window containing 
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the page from which the applet was launched is closed. 
This will cause the applet's stopO method to be called 
by Web browser. In its stopO method, the applet 
notifies the backplane that it has been stopped by 
calling the backplane's deregisterApp () method. 

Then a user typically requests logoff via 
menu, close box, etc. When such a request is received 
the backplane sends Logoff transaction, to the Web 
Server. The Backplane closes toolbar and directs the 
Web browser to logon URL. Then the backplane exits. 

As further shown in Figure 6, the homepage 
provides links to other Web pages. For example, if 
help hypertext is selected in step 122 from the 
application toolbar, a help URL is launched in a new 
browser window in step 124. Similarly, if customer 
support hypertext is selected in step 126, a customer 
support URL is launched in a new browser window in step 
128. If a user selects a marketing promotion hypertext 
in step 13 0, URL for new product information will be 
launched in a new browser window in step 132. If a 
product overview hypertext is selected in step 134, a 
URL pertaining to the product's features will be 
launched in a new browser window in step 136. If a 
user selects home in step 138, the home page will be 
redisplayed in step 139. 

User 

The present invention also includes a user 
unit for representing a user of a current session. The 
user unit is generally implemented as a COUser class 
extending java.lang. Object. The COUser class object 
holds information including a user profile, 
applications and their entitlements. In order to 
minimize network traffic, the amount of data carried by 
the COUser is minimal initially, and get populated as 
requests are processed. The requests are generally 
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processed by retrieving information from the order 
Entry service. The profile information is then stored 
and populated in the COUser object should such 
information be requested again. 

A COUser object is created when the user logs 
in f and holds the username and password of the user as 
an object in the COClientSession object. The session 
object is contained within the backplane, which manages 
the session throughout its lifetime. The code below 
illustrates how this occurs: 

// Within the backplane 

COClientSession session = new 

COClientSession () ; 

try { 

Session. logon ("username 11 , "password") ; 
} catch (COClientLogonException e) {...}; 
// Should the User object be required 
COUser user = session. getuser () ; 

The logon method of the COClientSession object 
communicates with the StarOE (Order Entry) server 
(Figure 2) , a back-end authentication mechanism, for 
authenticating the user. 

The COUser that may be obtained from the 
COClientSession immediately after the login process is 
very sparse. It includes a limited set of information 
such as username, a list of applications that user is 
entitled to, for example. The details of each 
entitlement information are retrieved at the time of 
actual processing with those information. 

StarOE 

As briefly mentioned, the StarOE server 39 of 
the networkMCI Interact system (Figure 2) is used to 
order, fulfill, and bill for, as well as administer, 
the suite of network applications, providing a 
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applications communicate to StarOE for all 
authentication, entitlement and system administration 
as well as order entry services. StarOE centrally 
5 processes these service requests for the individual 

applications by providing all order entry and security 
information or the "networkMCI Interact" suite of 
applications . 

The security information which the StarOE 

10 maintains and provides describes identification, 

authentication and access control used in the suite of 
applications. All access to the "networkMCI Interact" 
is controlled by userids and passwords, as explained 
herein. In addition, individual users are specifically 

15 granted access to only the necessary system objects, 

i.e., file, programs, menus, reports, etc. Access to 
these individual objects are based upon the customer 
privilege models, i.e., entitlements, stored in a 
StarOE database. Thus, all information regarding 

20 customers and their access levels for each product in 

the suite of network applications to which, the 
customers have subscribed are stored in a customer 
security profile database local to the StarOE. 
Accordingly, StarOE provides the ability to prevent 

25 unauthorized, non- customer access to "networkMCI 

Interact" data and applications; the ability to allow 
customers to access multiple enterprises with one 
userid; the ability to restrict authorized users to 
specific Intranet applications and databases based on 

30 applications ordered by the customer; and the ability 

for users to restrict view and/or update capabilities 
within an application or data set, i.e., customers may 
provide or restrict views of their "enterprise" data to 
subgroups within their organization. 

35 By utilizing the system of the present 

invention, customers no longer have to place manual 
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calls to order entry hubs when requesting order 
transactions. For example, users may be added to the 
system without an enterprises support team 
intervention. In sum, customers may manage their 

5 communications services in a secure environment and 

also, for example, monitor their network traffic via 
the Internet, as well as have a capability to add 
products and services to their account, in an automated 
fashion and all in one session without having to enter 

10 and exit the individual application services 

separately, and without having to contact a customer 
support representative . 

Figure 7 illustrates a general architectural 
overview of the StarOE component which includes a 

15 StarOE server 39 resident in a midrange computer, and 

an associated client application 154 running in a user 
platform having a web browser, hereinafter referred to 
as a StarOE client application. The StarOE server 39 
processes a number of transaction requests relating to 

20 authentication and entitlements, from other application 

services, both from the client and the application 
server 158 sides of the network. In addition, the 
StarOE server 39 receives transaction requests from the 
StarOE client application. The transactions are 

25 typically message driven and comprise requesting 

transactions and response transactions. The StarOE 
server 39 responds to the message requests 
by formulating transaction responses and transmitting 
them to the requesting servers and clients. 

30 

The StarOE client application 

The StarOE client application 154 is one of 
the client browser applications running in the Web 
browser 14, and provides a Web-based GUI interface 
35 implemented accordingly and conforming to the 

networkMCI Interact GUI interface standard for the 
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integrated suite of customer network management and 
report applications, as described herein. As 
described, the StarOE client application 154 is 
launched at the client initiation by the backplane 
object and generally includes Java applications and 
applets for providing a common Web -based GUI for 
interacting with customers at the frontend side. 

When a customer launches the StarOE 
application from the home page, the main window as 
illustrated in Figure 16, is presented. From this main 
window 1500, a customer may select to order and fulfill 
application services, request user id's, and create 
user security profiles for the "networkMCI Interact" 
suite of applications. The main window 1500 includes a 
menu bar 1506 with options to perform various StarOE 
tasks. The main window also includes a toolbar 1504, 
common to all networkMCI Interact applications. The 
toolbar 1504 has buttons that also perform the various 
StarOE functions. Typically, the user list is 
presented, i.e., displayed as a tree 1502, within the 
main window 1500. 

The menu options 1506 include: file menu 
options which includes a select enterprise option for 
allowing administrators to open a user list for a 
different enterprise, or add a new enterprise to their 
enterprise list, print option, and exit option which 
shuts down the StarOE application; edit menu option 
which includes add new application, modify and delete 
options; options menu which enables a global security 
setup for the toll free manager application; view menu 
which includes options to refresh the screen by 
retrieving the latest user list for the opened 
enterprise from the StarOE server and displaying the 
list on the screen, to expand all nodes in the user 
list, and to collapse all nodes in the user list; and 
help menu option which launches the help engine with 
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StarOE help text. The toolbar 1504 also includes the 
options for a select enterprise, refresh, expand all, 
collapse all, print and help options. 

A typical process flow logic for StarOE 
client application starts with the home page launching 
the StarOE client and passing a reference to a common 
user information object. This object includes the user 
id, and the default enterprise for that user. ' The main 
window 1500 having the menu to options 1506 and the 
toolbar 1504 is then presented. The StarOE client 
application then sends a transaction message "get 
StarOE security" including the user id, enterprise id, 
and the StarOE application code in the message. The 
StarOE server 39 returns racf id, an access level 
representing whether the user is an external admin, a 
member of an account team, an internal admin, or a 
customer support admin, for example. If the user that 
launches the StarOE application is an external admin, 
the user list is displayed immediately since external 
administrators may view only one enterprise. For 
external administrators, an enterprise name is 
retrieved from the StarOE server 39 by sending and 
receiving a "get user enterprise list" transaction 
request and response. 

If the user is not an external administrator, 
then a dialog is presented for the user to select 
which enterprise to view. When user selects an 
enterprise to view, a "get user list" transaction 
message having enterprise id is sent to the StarOE 
server 39 to retrieve a list of user ids, a list of 
applications for each user, an access type for each 
application, and reporting types for StarWRS (e.g., 
Toll Free, Vnet, Vision, CVNS) . The client application 
also sends a " get application list" transaction 
message to retrieve from the StarOE server 39 a list of 
application codes, description, and an application 
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array position. The user list is then displayed within 
the main window as shown at 1502. 

Every user list has a New User node 1502a as 
the first node under an enterprise 1502b. This node 
may be selected to order a new user. An existing user 
node 1502c may be selected to edit and add new 
applications for that user. When an existing user node 
1502c is selected, the edit/add new application options 
on the menu 1506 is enabled and disabled according to 
what applications the user already has. An existing 
user application node 1502d may be selected to 
edit/modify/delete options within the application. 

With regard to user selection of the select 
enterprise menu option or toolbar button in Figure 16, 
the browser displays the web page having a dialog box 
which enables an administrator to work with a different 
enterprise, as well as add an enterprise to their 
enterprise list and additionally includes the ability 
to set up new users or modify various options available 
to existing users. 

During the StarOE add or modify procedure 
described above, security information regarding 
customer entitlements for application services may also 
be initialized. For example, a screen may be presented 
for setting up Toll Free Network Manager ( "TFNM" ) 
security information and is displayed when TFNM is 
ordered or modified. Preferably, a user's TFNM 
security profile includes at least one corp id, with 
each corp id having an associated racf id. Preferably, 
a setup security object handles the process of setting 
up security for each application. A constructor for 
this object initializes the user id and a modify flag 
as passed in from the StarOE client application 154. 
The object retrieves the toll free hierarchy from the 
StarOE server 39 using the "get hierarchy" message. The 
client application 154 sends the enterprise id, and 
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toll-free flag in the request, and the StarOE server 39 
returns the list of toll-free corp ids for the 
enterprise. If the modify flag is set, a "get 
security' 1 message is sent to the server 39 to retrieve 
the user's TFNM security profile. As a displayed tree 
structure is loaded with each toll free corp id, racf 
id is entered by a user. When the submit button is 
pressed, the setup security object calls its send 
security method which causes the formatting and sending 
of "setTFNM security" message to the StarOE server 39. 
When the StarOE server 39 receives the message, it sets 
the security accordingly for the TFNM application. 

The StarOE administration component is also 
utilized to order, for example, to add or modify, 
various reporting options used during web based report 
generation by the nMCI Interact StarWRS system as will 
be described. Figure 17 is a sample StarOE screen 1540 
for adding and modifying reporting options which are 
used by the StarWRS. The StarOE displays the toll free 
hierarchy for security setup when toll free reporting 
is ordered or modified. The hierarchy includes a list 
of corp ids for a given enterprise, with each corp id 
1542 having a list of toll free numbers 1544 under it. 
The list may be displayed in a tree format. The 
reporting options at the toll free number level include 
unpriced reports (UR) , unpriced call detail (UCD) , and 
real time monitor reports. 

Typically, a user's toll free reporting 
security profile includes at least one toll free number 
with at least one reporting option associated. The 
client application 154 generally invokes an object to 
handle the reporting option changes and passes in the 
user id and a modify flag. This object then retrieves 
the toll free hierarch from the StarOE server 39 using 
the "get hierarchy" message. The client application 
154 sends the enterprise id, and toll free flag in the 
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request, whereby, the server 39 returns the list of 
toll free corp ids for the enterpriser If a modify 
flag is set, a "get toll-free security" message is sent 
to the server to retrieve the user's toll free security 
profile. 

As each corp ids is expanded, a "get toll- 
free numbers" message is sent to the server 39 asking 
for all the numbers for the corp id selected. As each 
toll free number is added, a search in the user's 
profile for that number is conducted. If the number is 
found, the report options are added next to number text 
as shown at 1546. Furthermore, if the number has been 
deactivated, a text "<inactive>" , for example, is added 
to the display as shown at 1548. The inactive numbers 
are not modifiable. When the unpriced reports or 
unpriced call detail check boxes 1541 are changed, the 
text next to the toll free numbers selected reflects 
the state of the check box. The check boxes depict 
report options to which a user has access for toll free 
numbers. When more than one toll free number is 
selected, the check boxes are marked unchecked. When a 
submit button is pressed, the object calls its send 
security class method which causes the formatting and 
sending of a "set user toll-free security" message to 
the StarOE server 39. 

It should be understood that besides 
performing various order entry and administrative 
functions for the TFNM application, other application 
services, including reporting for VNET, Vision, 
Broadband, Call Manager, and invoice reporting may be 
ordered and the. security information pertaining to each 
application may be modified in a similar manner. 

StarOE client application, 154 particularly 
provides screen displays by invoking associated class 
objects launched by the backplane unit as described 
above. The StarOE client application 154 employs a 
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Java application program and is implemented by 
extending the COApp class, one of common objects 
provided and utilized in the present invention. Because 
the client program 15 is not implemented as an applet, 
and also because the client program 154 employs the 
container Frame for customer display windowing 
purposes, the client program 154 runs, to a degree, 
independent of the browser within which the backplane 
is deployed. 

Referring back to Figure 7, the StarOE client 
application interacts with the StarOE server in 
providing various order entry functions for all 
applications as described above and, as described 
herein with reference to the back-end functionality of 
the nMCI Interact system. Communications between the 
StarOE client 154 and the server 39 typically use 
TCP/IP, running a UNIX process listening in on a known 
TCP port. 

In the preferred embodiment, as shown in 
Figure 7, the StarOE server 39 provides a number of 
processes for performing a number of specific 
functions. For example, a fulfillment process monitors 
new customers being added to the system and notifies a 
fulfillment house 298 accordingly (Figure 9) . The 
fulfillment house then may send appropriate 
subscription packages according to the information 
received from the fulfillment process to the new 
customer. Another process, a reconciliation process, 
may handle synchronization of data with a mainframe 
system database and also with databases associated with 
the individual fulfilling systems. Yet another 
process, a billing process, may handle directing 
billing information to different billing streams 157 
(Figure 7) . 

The StarOE server 39 further maintains a 
database 160 for storing all the "networkMCI Interact" 
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users and their security information such as passwords 
and application entitlements * and hierarchies describing 
the user's access privileges to specific application 
services/sub- services which may be requested by other 
application servers and clients in the network. 
Generally, the hierarchies are customer -defined during 
the order entry process, and describe the subdivision 
of calls into nodes arranged in a n-way tree. The 
"networkMCI Interact" back-end servers apply the 
hierarchy definitions to their data at report time when 
generating reports, typically as queries on a 
node-by-node basis to the result data set which was 
extracted using any other criteria supplied. The trees 
of the hierarchies have essentially arbitrary 
complexity, i.e., the number of nodes is unlimited . 
Each node is assigned calls according to a template of 
conditions. Conditions may be defined as a combination 
of one or more ANIs, corp IDs, ID codes, Card numbers, 
account codes, location/node ids, etc. These filters 
can be applied at any node in the tree. The 
hierarchies may be applied as both selection criteria 
(e.g., "report on all calls at these nodes or their 
descendants", in combination with other criteria) and 
roll-up targets (e.g., group the results in this report 
at this level in the tree) . These entitlement and 
hierarchies may be modified via the StarOE client 
application 154 executed at the customer workstation 
20. 

Referring to Figure 7, a process running in a 
StarOE client application process 154 sends transaction 
request messages via the nMCI Interact infrastructure, 
comprising, e.g., the web server cluster 24 and a 
dispatcher server 26 (Figure 2), to the OE server 39. 
The StarOE server 39 responds to requests by searching 
the security profile for the information requested, 
formulating appropriate transaction response messages 
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and transmitting them back to the requesting process. 
As an example, other during the login procedure, the 
client login process formulates a transaction message 
including a user name/password and a validation request 
for a given customer. The StarOE server 39 looks for 
the matching name/password pair in the security profile 
for the customer, and if the name/password pair is 
found, the server 39 formulates a valid user message 
response for the login process running in the client 
platform, including in the message the enterprise id, 
time zone, user id and password information and 
transmits the response via TCP/IP back to the login 
process. When the StarOE server 39 detects that the 
password has expired, the server 39 notifies the 
customer, via the client application 154 to change the 
password. The changed password is sent to the StarOE 
server 39 formatted in a message interface, "change 
password request,'' for example. The server 39 upon 
receiving the message updates the password for the 
given user in its user profile stored in StarOE 
database 160, and responds with appropriate return 
codes to the StarOE client 154. The login process, 
upon receiving the response may then continue with its 
normal course of processing. 

Another example of a service provided by the 
StarOE is retrieving an application entitlement list 
for a given customer. As described briefly above, an 
entitlement describes a privilege or authorization that 
a customer has. It describes what applications a 
customer may access and also describes what the 
customer can do within that application. In addition, 
it describes what back-end services that application 
and customer combination may access. For example, a 
customer may be entitled to use or access many 
applications and for each application, the customer can 
have a different set of entitlements. Thus, 
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entitlements may come in two different -sets : a first 
set specifying what the customer may do within the 
application, e.g., allow the customer to have update 
access to a particular view and only read-only access 
in a different view; and, a second set specifying what 
back-end services this particular application and 
customer may access. 

As described previously, all the information 
relating to entitlements for a given customer is stored 
in customer profile database 160 located with the 
StarOE server. When the backplane requests via TCP/IP 
the entitlement transaction, for example, in a "get 
application list" request message, the security module 
retrieves and transmits back via TCP/IP to the 
backplane the list of authorized applications 
accessible by given customer in, a transaction 
response. The backplane uses the list to determine 
which buttons on the "networkMCI Interact 11 home page 
should be activated, thus controlling access to 
products. Similarly, individual back-end application 
servers 158 may make a request for entitlements within 
that application for a given customer. For example, 
the reporting component of the "networkMCI Interact" 
system, herein referred to as "StarWRS" web-based ■ 
reporting system which provides a customer with their 
network priced and un-priced call detail data, 
generates a request for hierarchy data for Vnet, 
VISION, CVNS and Toll-free customers whenever reports 
need be generated. In response, the StarOE retrieves 
the corresponding hierarchy data and transmits them in 
real time to the StarWRS system as will be described. 

In providing the authentication, entitlement, 
and hierarchy information, including those described 
above, the StarOE server database 160 stores user 
profiles locally. Additional data needed are typically 
accessed from the enterprise host systems 15 . The 
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StarOE server 39 may be implemented as a concurrent 
server allowing simultaneous multiple client 
connections. The server 39 listens on a known port, 
and when a client connects, the server 39 forks a new 
process to handle the client connection. The server 39 
may also implement a thread to handle each client 
connection . 

The StarOE server 39 is preferably 
implemented utilizing object oriented programming 
(OOP) . As an example, when a "get hierarchy list" 
message is initiated at the client application to 
invoke retrieval of a toll free corp id list from the 
server 39, a "Hierarchy" class may be instantiated 
which includes a Get() method to determine which 
Hierarchy product is to be retrieved (e.g., Toll-free, 
Vnet/CVNS, or Vision) and to return the appropriate 
information. Another object may be invoked to format 
the data into a response message and return the message 
back to the client. As another example, when a "get 
application list" request message is initiated at the 
client application, an "Application" class may be 
instantiated which encapsulates the interface into a 
database table (not shown) having applications 
information. Particularly, the Get() method in this 
class accesses the Applications table in the database 
and return the list of application codes and their 
descriptions . 

Figure 8 is a high level input process flow 
diagram, illustrating inputs to the StarOE server 39 of 
the nMCI Interact system. Through the StarOE server, 
the integrated interface system of the invention 
handles a wide variety of key functions for the suite 
of network applications. Each application will, herein 
forth, be also referred to as a fulfilling system, 
having a fulfilling client and a fulfilling server. 
The system of the present invention handles security 
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and authentication requests from both the client and 
server sides of each fulfilling system as shown in 
282a-d and 284. These requests are automatically 
generated whenever the customer makes a request of the 
server. For example, they are generated when a 
customer clicks on the icon from the homepage (Figure 
4) for a service such as TFNM. 

In addition, as mentioned, when a customer 
first logs on, the customer is presented with a dialog 
box prompting for user ID and password. When the 
customer clicks a submit button, for example, the 
backplane (or platform) verifies the customer is valid 
by inquiring with the StarOE system as shown in 286. 
The return response is either "invalid user /password" 
or "valid user". When the customer has been 
authenticated, the customer is then presented with a 
list of authorized applications. This list determines 
which buttons, for example, representing each 
application are active, thus controlling customer 
access to products and services. 

In addition, also shown in 286, the customer 
may be issued a temporary password with the customer's 
fulfillment package, which enables a user to log into 
the system the first time. 

Information may also be entered and requested 
by a number of sites other than a user platform. For 
example, order entry "OE" Hubs 288 may enter 
information directly into the StarOE database 160 to 
register new customers to the integrated suite of 
network applications. They may also access the data in 
StarOE directly to modify customer information, and to 
add or remove subscribed services. 

Other inputs to the StarOE server may include 
entitlement data from a legacy order entry system 
referred to as Network Capabilities System ("NetCap") 
290 and from a circuit order management system ("COMS") 
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291. For example, the NetCap mainframe 290 may send 
the appropriate hierarchy of toll-free numbers for a 
specific customer in response to registry message 
registering the new customer to the mainframe 290. The 
hierarchy of toll-free numbers describes the new 
customer's entitlements to the TFNM services. This 
hierarchy may be used by other services in the 
integrated suite of network applications, for example, 
the StarWRS reporting application. 

Additional authentication and entitlement 
data may be transmitted from a corporate order entry 
system ("CORE" ) 292 which generates two sets of 
hierarchy files on a daily basis. One set comprises 
deltas only, the other comprises a full hierarch. 
Notification is made to the StarOE when these are 
available. StarOE performs a reconciliation process to 
update the hierarchy files. Figure 9 is an output 
process flow diagram, illustrating outputs and 
responses from the StarOE server 39 to the requesting 
systems and processes. An example of an output is an 
authentication response to the client side of the 
individual applications, e.g., call manager 1100, 
priced reporting system 400, etc., as well as the 
backplane. In addition, a list of accessible 
applications for a given customer, is output to the 
backplane platform via platform web servers 24. The 
StarOE also outputs various updated data to database 
systems associated with specific individual 
applications in the suite of network applications. In 
addition, the individual fulfilling systems receive 
messages from the StarOE regarding modifications 
effected by a customer interaction. For example, as 
part of the reconciliation process, the StarOE may pass 
a list of toll free numbers which represent services 
which are to be discontinued and deleted from Traffic 
View. Upon receipt of this information, the Traffic 
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View server sends another message to a system 
responsible for collecting call detail information 
which system then discontinues collection of call data 
for the numbers deleted. Another example output to 
individual fulfilling system is hierarchy data to 
reporting fulfilling systems 4 00, 500 when a customer 
requests reports. The customer hierarchy data is sent 
in real time by the StarOE for up-to-date report 
information. 

StarWRS 

As mentioned herein, the data architecture 
component of the networkMCI Interact system focuses on 
the presentation of real time (un-priced) call detail 
data and reports, such as presently provided by MCI's 
TrafficView ("TVS") Server, and priced call detail data 
and reports, such as presently provided by MCI's 
operational data store "StarODS" Server. 

Referred to as "StarWRS", the WWW/Internet 
Reporting System 200, as shown in Figure 10, provides a 
client, middle -tier service and application proxy 
components enabling customers to request, specify, 
customize, schedule and receive their data and account 
information in the form of reports that are generated 
by the various back-end application servers. As will 
now be described in detail, the StarWRS reporting 
system 200 comprises the following components and 
messaging interfaces : 

1) those components associated with the 
Client GUI application front end including a report 
requestor client application 212, a report viewer 
client application 215 and, an Inbox client application 
210 which implement the logical processes associated 
with a "Java Client", i.e., employs Java applets 
launched from the backplane (Figure 3) that enable the 
display and creation of reports and graphs based on the 
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fields of the displayed reports, and allows selection 
of different reporting criteria and options for a given 
report; and, 

2) those middle -tier server components 
enabling the above-mentioned reporting functionality 
including: a Report Manager server 250, a Report 
scheduler server 260, and an Inbox Server 270. 
Supporting the StarWRS reporting functionality as will 
be described are the StarOE client and corresponding 
StarOE server 39 applications. 

The Report Manager ("RM") server 250 is an 
application responsible for the synchronization of 
report inventory with the back-end "Fulfilling" StarODS 
server 400 and Traffic View server 500; retrieval of 
entitlements, i.e., a user's security profiles, and 
report pick list information, i.e., data for user 
report customization options, from the StarOE server 
39; the transmission of report responses or messages to 
the Dispatcher server 26; the maintenance of the 
reporting databases; and, the management of metadata 
used for displaying reports. In the preferred 
embodiment, the RM server 250 employs a Unix daemon 
that passively listens for connect requests from the 
GUI client applications and other back-end servers and 
deploys the TCP/IP protocol to receive and route 
requests and their responses. Particularly, Unix 
stream sockets using the TCP/IP protocol suite are 
deployed to listen for client connections on a well- 
known report number on the designated host machine. 
Client application processes, e.g., report requestor 
212, desiring to submit report requests connect to RM 
250 via the dispatcher 26 by providing the port number 
and host name associated with RM 250 in a request 
message. Request messages received by the RM server 
are translated into a "metadata" format and validated 
by a parser object built into a report manager proxy 
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250' that services requests that arrive from the GUI 
front -end. If the errors are found in the metadata 
input, the RM 250 will return an error message to the 
requesting client. If the metadata passes the 
validation tests, the request type will be determined 
and data will be retrieved by the fulfilling server in 
accordance with the meta data request after which a 
standard response is sent back to the requesting 
client. As shown in Figure 10, interface sockets 252 
are shown connecting the Dispatcher server 26 and the 
RM server 250 and, other socket connections 254, 256 
are shown interfacing with respective back end servers 
400 and 500. In one embodiment, a back-end midrange 
application known as the TrafficView System receives 
the metadata requests to provide unpriced traffic call 
detail and reporting data through messaging interface 
256 to the Report Manager. Additionally, a back-end 
midrange application known as the StarODS server 
receives report requests for priced call detail data 
through a Talarian smart socket messaging interface 3 50 
to the Report Manager. Additionally, as shown in 
Figure 10, the priced and unpriced data is FTP'd 
directly to the Inbox Server and a notification message 
is sent to the report manager server 250 from the 
Traffic View server 500. Although not shown in Figure 
10, it should be understood that the RM 250 server can 
manage reporting data for customer presentation from 
other back-end and legacy servers including, e.g., 
Event Monitor and Service Inquiry servers, etc., in 
order to present to a customer these types of network 
management and reporting data. 

The report manager server additionally 
utilizes a database 258, such as provided by Informix, 
to provide accounting of metadata and user report 
inventory. Preferably, an SQL interface is utilized to 
access stored procedures used in processing requests 
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and tracking customer reports. A variety of C++ tools 
and other tools such as Rogue Wave's tools.h++ are 
additionally implemented to perform metadata message 
parsing validation and translation functions. 

The Report Manager server 250 additionally 
includes the scheduling information, however, a report 
scheduler server component passes the report request to 
the back-end fulfilling servers 400, 500 at the 
scheduled times. 

As shown in Figure 10, the Report Scheduler 
("RS" ) server component 260 interfaces directly with 
the Report Manager server 250 to coordinate report 
request scheduling and processing. It should be 
understood that the respective report management and 
scheduling functions could be performed in a single 
server. Particularly, the RS 260 is a Unix program 
deploying Unix stream sockets using the TCP/IP protocol 
suite to send requests to the back-end fulfilling 
servers such as the StarODS server 400, TVS server 500, 
at pre- specified times, and receives their responses. 
As shown in Figure 10, RS interface socket connections 
264, 266 are shown interfacing with respective back end 
servers 400 and 500. In the case of priced billing 
data from StarODS 400, report requests are published by 
the RS server 260 to a pre-defined subject on the 
Talarian Server. When handling other incoming messages 
published by back end servers using Talarian 
SmartSockets 4.0, another daemon process is necessary 
that uses Talarian C++ objects to connect their message 
queue and extract all messages for a given subject for 
storage in a database table contained in database 263. 
Each message includes the track number of the report 
that was requested from the fulfilling server. 

From the report requestor interface, the user 
may specify the type of reporting, including an 
indication of the scheduling for the report, e.g., 



-58- 



WO 99/15979 



PCT/US98/20170 



hourly, daily, weekly or monthly. For priced data the 
user as the option of daily, weekly, -or monthly. For 
real-time, or unpriced data, the user has the option of 
hourly, daily, weekly or monthly. The report schedule 
interface additionally enables a user to specify a 
pager or E-mail account so that an e-mail or pager 
message may be sent to indicate when a requested report 
is in the Inbox server 270. 

The Inbox Server component 270 serves as the 
repository where completed report data and event 
notification data are stored, maintained, and 
eventually deleted and is the source of data that is 
downloaded to the client user via the dispatcher 
(Figure 2) over a secure socket connection 272. It is 
also a Unix program that is designed to handle and 
process user requests submitted in metadata format 
using an Informix database. Once report results are 
received from the StarODS 400 and TVS 500 and any other 
back-end or fulfilling servers (not shown) , the Report 
Manager server 250 communicates the corresponding 
report metadata to the Inbox server 270 over socket 
connection 274 as shown in Figure 10. The metadata 
will be stored in the Inbox server database 273 along 
with the report results. Thus, if the metadata is 
required to be changed, it will not interfere with the 
information needed to display the reports contained in 
the Inbox. Additionally, as shown in Figure 10, the 
Inbox server interfaces with the report scheduler to 
coordinate execution and presentation of reports. 

As described above, the StarOE server 39 and 
database 160 is the repository of user pick lists and 
user reporting entitlements. Particularly, it is shown 
interfacing with the Inbox server 270 and report 
scheduler servers 260. The Report Manager server does 
include information in the report metadata that will 
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tell the Report Requestor client application it needs 
to get information (e.g., Pick Lists) from the StarOE 
server 39. 

With regard to the front -end client GUI 
components, the above-mentioned Inbox client 
application 210 functions as an interface between the 
client software and the Inbox server 270 for presenting 
to the customer the various type of reports and 
messages received at the Inbox including all completed 
reports, call detail, and news. Preferably, the 
messages for the user in the inbox are sorted by type 
(report, call detail) and then by report type, report 
name, date, and time. 

Particularly, the Inbox client application 
uses the services of the backplane (Figure 3) to launch 
other applications as needed to process report 
messages. The inbox will also use the services of the 
data export objects to provide a save/load feature for 
inbox messages, and, is used to provide a user- 
interface for software upgrade/download control. Inbox 
messages are generated by the versioning services of 
the backplane; actual downloads will be accomplished by 
a request through the inbox. 

In the preferred embodiment, the inbox client 
is able to receive information on multiple threads to 
allow a high priority message to get through even if a 
large download is in progress. Typically, the browser 
is configured to allow more than one network connection 
simultaneously, i.e., the polling thread on the client 
uses a separate connection to check for new messages, 
and starts a new thread on a new connection when a new 
message is detected. In this way, multiple messages 
may be downloaded simultaneously. 

The Report Requestor application 212 is a 
client application enabling user interaction for 
managing reports and particularly includes processes 
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supporting: the creation, deletion, and editing of the 
user's reports; the retrieval and display of reports 
based on selected criteria; the display of selected 
option data; and the determination of entitlements 
5 which is the logical process defining what 

functionality a user can perform within the StarWRS 
application. In the preferred embodiment, a Report 
request may be executed immediately, periodically, or 
as "one- shots" to be performed at a later time. As 

10 described herein, the report scheduler service 

maintains a list of requested reports for a given user, 
and forwards actual report requests to the appropriate 
middle- tier servers at the Appropriate time. 
Additional functionality is provided to enable 

15 customers to manage their inventory, e.g., reschedule, 

change, or cancel (delete) report requests. 

The Report Viewer application 215 is a GUI 
Applet enabling a user to analyze and display the data 
and reports supplied from the fulfilling servers such 

20 as ODS 400, Traffic View (TVS) 500, and other systems 

such as Broadband and toll free network manager. 
Particularly, all reporting is provided through the 
Report Viewer client application 215 which supports 
text displays, a spreadsheet, a variety of graphic and 

25 chart types, or both spreadsheet/graph simultaneously, 

and, is launched from the inbox client 210 when a 
report is selected. The Report Manager 250 includes 
and provides access to the metadata which is used to 
tell the Report Requestor what a standard report should 

30 look like and the "pick -list" options the user has in 

order for them to customize the standard report. It is 
used to tell the Report Viewer client how to display 
the report, what calculations or translations need to 
be performed at the time of display, and what further 

35 customization options the user has while viewing the 

report. It additionally includes a common report view 
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by executing a GUI applet that is used for the display 
and graphing of report data and particularly, is 
provided with spreadsheet management functionality that 
defines what operations can be performed on the 
spreadsheet including the moving of columns, column 
suppression, column and row single and multiple 
selection, import and export of spreadsheet data, 
printing of spreadsheet, etc. It is also provided with 
report data management functionality by defining what 
operations can be performed on the data displayed in a 
spreadsheet including such dynamic operations as 
sorting of report data, sub -totaling of report data, 
etc. Furthermore, the report viewer 215 is provided 
with functionality enabling the interpretation of Meta 
Data; and, functionality enabling communication with 
the Backplane (Figure 3) . The report viewer 
application 215 will also be able to accept messages 
telling it to display an image or text that may be 
passed by one of the applications in lieu of report 
data (e.g., Invoice, Broadband report, etc.) 

By associating each set of report data which 
is downloaded via the Inbox server 270 with a 
"metadata" report description object, reports can be 
presented without report- specif ic presentation code. 
At one level, these metadata descriptions function like 
the catalog in a relational database, describing each 
row of a result set returned from the middle tier as an 
ordered collection of columns. Each column has a data 
type, a name, and a desired display format, etc. 
Column descriptive information will be stored in an 
object, and the entire result set will be described by 
a list of these objects, one for each column, to allow 
for a standard viewer to present the result set, with 
labeled columns. Nesting these descriptions within one 
another allows for breaks and subtotaling at an 
arbitrary number of levels. 
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The same metadata descriptions may be used to 
provide common data export and report printing 
services . When extended to describe aggregation levels 
of data within reporting dimensions, it can even be 
used for generic rollup/drilldown spreadsheets with 
" just- in- time" data access. 

The metadata data provide may include 
geographic or telecommunications -specific information 
e.g., states or NPAs. The report viewer may detect 
these data types and provide a geographic view as one 
of the graph/chart types. 

An overview of the report request/scheduling 
process 600 implemented by StarWRS Report Manager and 
Report Requestor tools will now be described. 

After preliminary logon, authentication and 
verification of StarWRS web-based reporting 
entitlements, as described above wit respect to Figures 
4-6, the user may select the Report Requestor icon 
83(a) from the home page screen display 79(a) of Figure 
5(a), which initiates display of a StarWRS report 
requestor web page. 

Figure 12(a) illustrates an exemplar dialog 
box 1550 provided on the report requestor web page that 
is presented to the user after the logon and 
authentication process. From this dialog, the user is 
enabled to edit an existing report maintained in the 
report manager inventory, by selecting "edit" button 
1551, generate a new report by selecting "new 11 button 
1553, copy an existing report by selecting button 1554, 
or delete an existing report by selecting button 1555. 
When creating a new report or editing an existing 
report, the user may enter the desired reporting 
options including: 1) the report product, as indicated 
by menu 1558, and which includes toll-free, vision, and 
Vnet options; 2) the report category, as indicated by 
menu 1559, and which includes options for: analyzing 
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traffic, call center, call detail, checking calling 
frequencies, financial, marketing, monitoring usage, 
and telecommunications categories; 3) the report type, 
as indicated by menu 1560, and which includes priced 
call detail data or traffic data options; and 4) a 
report direction, as indicated by selection areas 1563, 
and which includes inbound, outbound, or both 
directions . 

Referring to the flow chart of Figure 11(a) 
depicting the StarWRS reporting options, user selection 
of the report product, report category, report type, 
and report direction, is indicated at step 320. 
Additionally, at step 325, the user may select the 
report format associated with a reporting category. 
For example, in the screen display of Figure 12(a), 
associated with the analyze traffic report category, 
the report format options indicated in selection field 
1565 include the following: area code summary, country 
code summary, state summary, frequent numbers, payphone 
report and review calls options. For the financial 
report category, report formats include: longest calls, 
most expensive calls, payphone report, and area code 
summary; for marketing report category, report formats 
include: country code summary, state summary, frequent 
numbers, frequent area code summary, frequent state, 
and frequent cities. For the Telecommunications report 
category, report formats include: call duration 
summary; for the call center report category, report 
formats include: most active toll free numbers, state 
summary, and country code summary. For the monitor 
usage report category, report formats include: longest 
calls, most expensive calls, most active calling card 
and most active toll free numbers. For the check 
calling frequencies report category, report formats 
include: frequent numbers, frequent area code, frequent 
state and frequent cities. It should be understood 



-64- 



WO 99/15979 



PCT/US98/20170 



that enablement of any of these reporting options is 
based according to predefined user entitlements. That 
is, as described above, a "Get User Security" message 
with a reporting application set, and a "Get User 
Report Security" message are sent to the StarOE server 
39 via the Dispatcher server 26 to retrieve that user's 
detailed security profile (entitlements) for a user 
that has the reporting application option. These 
entitlements include a list of all the report products, 
i.e., Vnet, Vision, Toll free, report types (priced or., 
unpriced) and the report categories that are available 
for that user. 

In accordance with the user report 
selections, if a report had already been created and 
maintained in the report manager database, it will be 
displayed in the report inventory field 1568 of Figure 
12(a). Referring back to Figure 11(a), at step 326, a 
determination is made as to whether an existing report 
from inventory is selected. If an existing report is 
not selected then the user is prompted to generate a 
new report according to customization options that the 
user is entitled for the selected report product, 
category, type, etc., as indicated at step 330. If an 
existing report is selected at step 326 based on the 
report product, category type, etc., then the user is 
prompted at step 328 to select from among the following 
options: a report edit, option, as shown at step 335; a 
report delete option, in which case the selected report 
will be deleted at steps 338 and 339; and, a report 
copy option, in which case an existing report will be 
copied, e.g., for subsequent editing, as shown at steps 
340 and 341. 

Whether creating a new report or editing an 
existing report, the user is enabled to select 
customization options as indicated at step 330, Figure 
11(a). Figure 12(b) illustrates the dialog screen 1596 
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presented to the user showing all the report 
customization categories for building a new report and 
editing an existing report. From this screen and 
related report building dialog boxes, all of the 
initial values for retrieving the MetaData, 
customization options and GUI builder options from the 
report manager server 250 necessary to build (edit) a 
report are provided in accordance with the user's 
entitlements. Thus, in view of the exemplar web page 
shown in Figure 12 (b) , a user may provide the following 
customization and report builder options as indicates 
in the field 1570: general customization options, by 
selecting field 1571; layout customization options, by 
selecting field 1573; access customization options, by 
selecting field 1575; hierarchy customization options, 
by selecting field 1577; geographic customization 
options, by selecting field 1578; and, notification 
customization options, by selecting field 1579. For 
the following description regarding Figure 12(b) it is 
assumed that the area code summary format had been 
selected, however, it should be understood that the 
same principles apply to any selected format . 

With regard to the "general" customization 
options, the user is enabled to specify or change the 
report title, by selecting field 1571a, report 
description, by selecting field 1571b, and the report 
schedule, by selecting field 1571c. For the example 
selection of report title customization shown in Figure 
12 (b) , the right hand field 1580 will present the user 
with a field 1581 for entering the title of the report. 
If an existing inventory report had been selected, then 
the field 1580 will be display the existing title. 
Generally, for each of the customization screens 
displayed for existing reports, Report Manager will 
autopopulate the right hand field 1580 with the 
existing report values. 
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When selecting the report schedule 1571c , the 
user is presented with a screen 1597, as shown in 
Figure 12(c). The entry options for selection in the 
right hand field 1580 includes: selection of time zone, 
by menu choice 1582; selection of the report schedule 
radio buttons 1583 to specify the report as recurring, 
daily, weekly, monthly, or hourly entry field the 
nature of screen; a time range for the report as 
specified by entry fields 1584; and, a date range for 
the report as specified by entry fields 1585. The user 
may also specify the report as a "one -shot" by 
selecting radio button 1586. 

Referring back to exemplar screen shown in 
Figure 12(b), with regard to the layout customization 
options, the user is enabled to specify or change the 
number of report rows, by selecting field 1573a, and 
specify or change the report columns, by selecting 
field 1573b. For example, selection of report columns 
customization will present the user with a columns 
customization screen such as example screen display 
1598 presented as shown in Figure 12(d). In Figure 
12(d), the right hand field 1580 indicates a column tab 
1587, and a sorts tab, 1588. The column tab enables 
the user to specify add or remove columns, with the 
selection of individual columns names provided in field 
1589. An example description of the column headers for 
an example selection of columns is shown in field 1590. 

Referring back to Figure 12 (d) , selection of 
report sorts customization tab 1588 will present the 
user with a sorts customization screen such as example 
screen display 1599 presented as shown in Figure 12(e). 
The sorts tab enables the user to specify columns to be 
sorted in an available sorts selection field 1591, 
whether totals are to be made, whether the column data 
to be provided is in ascending or descending order, for 
example, as provided by selection of buttons 1592, 
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shown in Figure 12(e). In the preferred embodiment, 
the Report Manager provides the customer with the 
ability to specify select columns as primary and 
secondary sorts. The user may specify additional 
secondary sorts in addition to the default sorts. For 
example, the user may provide the following sorts: for 
a Longest Call Report, a primary sort is Number of 
Minutes in descending order. For a Most Expensive Call 
Report, the primary sort is dollars in descending 
order . 

Referring back to exemplar screen shown in 
Figure 12 (b) , with regard to the access customization 
options, the user is enabled to specify or change an 
accounting "IDACC" code or supplemental code, by 
selecting field 1575a, and specify or change the 
inbound access type, by selecting field 1575b. For 
example, selection of inbound access customization 
presents the user with a web page having an inbound 
access customization screen such as example screen 
display 1601 presented as shown in Figure 12(f). In 
Figure 12(f), depending upon the selected report 
format, the right hand entry field 1604 presents the 
user with the following selectable access types: dial 
1, card, dedicated, 800 Remote Access, Direct: Dial 
fax, store/forward fax, 800 Business line (highlighted 
in the Figure 12(f)), 800 wide area telecommunications 
service, 800 dedicated, 800 Network Call Redirect, 
local, cellular. 

Referring back to exemplar screen shown in 
Figure 12 (b) , with regard to the hierarchy 
customization options, the user is enabled to specify 
or change the billing location by selecting field 
1577a. Upon selection of the billing location 
customization option, the user is presented with a web 
page having a customization screen such as example 
screen display 1603 presented as shown in Figure 12 (g) . 
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In Figure 12 (g) , depending upon the selected report 
format, the right hand screen presents the user with 
three tabs: a corporations tab 1607, a search tab, 
1608, and, a selected items tab 1609. When selected, 
the corporations tab 1607 enables the user to add or 
remove a corporate ID to/from a billing location 
hierarchy in the entry field 1610. A search of 
corporate IDs may be performed by selecting the search 
tab 1608, and items that have been selected may be 
displayed in a field (not shown) presented by selection 
of the selected items tab. Likewise, referring back to 
exemplar web page screen shown in Figure 12 (b) , with 
regard to the geographic customization options, the 
user is enabled to specify or change the billing 
location by selecting field 1577a. Upon selection of 
the billing location customization option, the user is 
presented with a web page having a customization screen 
such as example screen display 1611 presented as shown 
in Figure 12 (h) . 

In Figure 12 (h) , depending upon the selected 
report format, the right hand screen presents the user 
with three tabs: a countries tab 1612, a search tab, 
1613, and, a selected items tab 1614. When selected, 
the countries tab 1612 enables the user to select, add 
or remove a country that may be a subject for reporting 
as provided in the entry field 1620. A search of 
countries may be performed by selecting the search tab 
1613, and items that have been selected may be 
displayed in a field (not shown) presented by selection 
of the selected items tab 614. 

Referring back to exemplar screen shown in 
Figure 12(b), with regard to the notification 
customization options, the user is enabled to specify 
report notification by paging, by selecting field 
1579a, and, report notification by e-mail, by selecting 
field 1579b. Upon selection of the paging notification 
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option, the user is presented with a web page having a 
customization screen (not shown) presenting the user to 
select or enter that user's page number, PIN number and 
a paging message description. Upon selection of the e- 
mail notification option, the user is presented with a 
web page having a customization screen (not shown) 
presenting the user to select or enter that user's e- 
mail address. 

As mentioned above with respect. to Figure 10, 
the Report Requestor client application 212 gains 
access to the metadata stored at the Report Manager 
server 250 through messaging. Particularly, as 
hereinafter described, a message generated by the 
Report Requestor in accordance with, the user request 
is first received by the report manager proxy 250'. In 
the preferred embodiment, the report manager proxy 
comprises a set of tools in the form of reusable 
objects, preferably written in C++ code, or the like. 
For example, a parser object tool is employed to 
decompose the Metadata messages sent by the report 
requestor 212 to validate the message. If errors are 
found in the Metadata input, the RM will return an 
error message to the requesting client. If the 
Metadata passes the validation tests, the request type 
is then determined and the appropriate service will be 
invoked after which a standard response is sent back to 
the requesting client. 

The Report Manager 250 implements stored 
procedures to translate the message, perform the 
request, and send the information back to the Report 
Requestor 212 which uses the metadata to determine what 
a standard report should look like, the customization 
options the user has, and the types of screens that 
should be used for the various options (i.e., single 
selection, multiple selections, etc.). 
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It is understood that the selection of 
available standard template reports is based on the 
user's entitlements. 

The following types of metadata requests and 
responses that may be generated by the StarWRS Report 
Requestor 212 and Report Manager 250 components 
include: 1) Get/Send report template list (GRTL/SRTL) - 
which request enables retrieval of the list of all 
standard report templates for all products and is used 
only to obtain general report information, e.g., report 
title, description, etc.; 2) Get/Send report template 
detail (GRTD/SRTD) - which request retrieves the 
details of a specific standard report template; 3) 
Get/Send user report list (GURL/SURL) - which request 
retrieves the list of all user reports for the report 
format selected from a user report table and is used 
only as a request for general report information, e.g., 
report title, status, etc.; 4) Get/Send user report 
detail (GURD/SURD) - which request retrieves the details 
of a specific user's report; 5) Add report 
definition /Acknowledgment (ARD/ARDA) - which requests 
addition of a user -created report to a user report 
table. If the report is a scheduled report, this 
request is also communicated to the fulfilling server 
at the time the report is due; 6) Delete report 
definition/Acknowledgment (DRD/DRDA) - which request 
deletes a user- created report from the user table; 7) 
Copy report definition/Acknowledgment (CRD/CRDA) - which 
request creates a duplication of the report the user is 
editing (other than the report title) and creates a new 
report ID for it; 8) Update Reporting 
Schedule/Acknowledgment (URD/URDA) - which request 
updates the scheduling information on a report without 
having to send a Delete and Add request; and, 9) Get 
Pick List/Acknowledgment (GPL) - which request enables 



WO 99/15979 



PCT/US98/20170 



the Report Requestor 212 to get a pick list provided by 
StarOE server. 

Having described the functionality of 
selecting and/or generating a report and customizing 
5 it, reference is now had to Figure 1Kb) which 

describes the next step 350 of presenting the user with 
report run and save options* Particularly, in the 
prefierred embodiment, as shown in each of the 
customization screens (Figures 12 (b) - 12 (h) ) , the user 

10 may select a save and exit option, depicted in Figure 

12(b) as button 1562 or a save and run option, depicted 
in Figure 12(b) as button 1563. In either scenario, an 
WRSEdit object enables a WRSScnMgr object to save the 
report to the RM server. The WRSScnMgr object launches 

15 each screens save method which communicates with the 

DataManager object to place the screens data in its 
corresponding WRSNode. Once all of the WRSNode objects 
have been updated, the WRSScnMgr object calls the 
DataManager object's SaveReport method to build a hash 

20 table to contain all of the report's data. The 

CommunicationManager utilizes the RptManagerMsg object 
to create the ARD metadata message from the hash table, 
the WRSCommWrapper for direct communication with the 
backend, and the WRSReportManagerUtil Parser to handle 

25 any errors thrown by the server. The Report Manager 

creates the Dispatcher object, and utilizes the 
services of the RmParser class and validation objects. 
Upon determining that the client has sent a valid 
message, the appropriate member function is invoked to 

30 service the request. The response is built inside the 

esgl wrapper function after obtaining the necessary 
information through the stored procedure from the RM 
database. The Report Manager creates the 
RMServerSocket object and sends the ARDA message back 

35 to the client. When a report is submitted the selected 
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report type and reporting criteria are sent to the 
Report Manager. 

As illustrated in Figure 1Kb), at step 355, 
in reference to user selection of a Save and Run report 
option, the report is marked as scheduled and saved in 
the Report Scheduler server 260 via the report Manager. 
Subsequently, as indicated at step 360, the Report 
Scheduler server 260 sends the ARD message to the 
fulfilling server which queues the report and runs the 
report at the specified time(s), as indicated at step 
365. 

With respect to the process for generating a 
report for StarODS priced call detail data, and, for 
TVS unpriced call detail data, generally, whether the 
report is to be currently run for immediate ad hoc 
reporting, or, is scheduled for normal scheduled 
reporting, the following sequence of operations, as 
indicated at steps 370-395, Figures 1Kb) - 11(c), are 
performed: First, in response to receipt of the ARD 
message, e.g., submitted to the fulfilling server by 
the Report Scheduler, the fulfilling server completes 
the report and compresses the report/data, as indicated 
at step 370. Then, the report/data is "pushed", 
implementing FTP, to the fulfilling server's directory 
on the Inbox server 270, as indicated at step 373. 
Each application server, e.g., TVS server 550 (Figure 
10) , is responsible for generating unique file names 
within their directory on the Inbox server 270. For 
example, the following directory and file naming 
conventions used for reports generated by the 
Traf f icView server are labeled inbox\f iles\tvs with 
text files having the suffix * . txt or *.txt_zip 
(compressed) , and comma separated files having a suffix 
*.csv or *.csv_zip ( compressed). The fulfilling 
server then verifies that the FTP process was 
successful, as indicated at step 376 , and, at step 
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379, a notification is sent by the fulfilling server to 
the Report Manager to notify the Report Manager server 
250 of the location of a scheduled report. This is 
accomplished by using a "NRL" metadata message. 

In the preferred embodiment, the NRL message 
received by the RM server 250 includes parameters 
verifying whether or not the FTP process was 
successful. If it was successful, then the fulfilling 
server messages the Inbox that the file has been 
transmitted successfully by transmitting the report 
name (filename) and location. When the fulfilling 
server encounters a problem executing a report, a 
notification is sent to the Report Manager. 
Particularly, an error flag is placed in the status 
field of the User_report by the Report Manager which is 
displayed to the user during Report Request. The error 
message description will be placed in a text file and 
FTP f d to the fulfilling server's report location on the 
Inbox server (e.g., \inbox\f iles\tvs) by the fulfilling 
server. 

Referring to Figure 11(b), step 379, once the 
RM server 250 has received the NRL message from the 
fulfilling server, it verifies the file's presence, as 
indicated at step 382. The RM server 250 then builds a 
metadata file, e.g., by compressing the appropriate 
metadata (for displaying the report) into a .MTD file, 
as indicated at step 385. This .MTD file is utilized 
by the Report Viewer to know how to display the report. 
The Report Manager server creates a file including the 
metadata using the same file name as the report/data 
file, but having the following suffix: *.mtd or 
*.mtd_zip indicating a metadata or compressed metadata 
file, respectively. 

Once the metadata file corresponding to the 
requested report is built by the Report Manager, the RM 
ftp's the .MTD file to the Inbox server, as indicated 
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at step 388, Figure 11(c). The RM server additionally 
updates the User_report table status field with a 
status "C" indicating completion, as indicated at step 
391. 

Once the Report Manager has updated the 
status field, the RM server 250 then adds the report to 
the Inbox server, as indicated at step 393. 

In an example metadata message indicating to 
the Inbox server that an unpriced TVS fulfilling server 
report is available, the RM server supplies a metadata 
"A" message to the Inbox indicating the FTP file 
location. Via the report viewer, the report is now 
available for viewing, downloading, saving, or printing 
by the user. 

Particularly, as shown in the exemplary nMCI 
home page in Figure 5(a), the nMCI Interact "Message 
Center" icon 81 may be selected which will cause the 
display of a web page including the message center 
dialog box 1510 such as shown in Figure 13(a). 
From the dialog box 1510, a user may select from among 
three tabs, a news tab 1512, a reports tab 1513 and a 
data tab 1514. Selection of the reports tab 1513 
enables the retrieval of both a data file and a 
metadata file from the Inbox Server corresponding to 
those reports that have been run and available for 
customer viewing. Information provided for display by 
the message center display 1510 is provided by the 
User_table which keeps track of the status of all 
reports for a particular user. Particularly, by 
double- clicking a chosen report, a report viewer 
application is enabled to display the chosen report on 
a web-page. Figure 13(b) illustrates an example 
web-page presenting a text viewer screen 1515 enabled 
by selecting the Highlighted report 1514 in Figure 
13(a). 
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Referring back to Figure 10, the Report 
Viewer 215 interfaces with the user's Inbox 210 for 
presenting to the customer the various type of reports 
received at the Inbox. Preferably, all Report 
5 Requestor and Report Viewer applications communicate 

with the RM server 250 through the use of the common 
object communication classes. 

It should be understood that fulfilling 
servers such as the Broadband, and Toll Free Network 

10 Manager 500, and StarODS 400, Report Scheduler server, 

and any other back-end or fulfilling servers (not 
shown) , send report results and event notifications to 
the inbox server 270. The fulfilling servers, and 
Report Manager server may communicate to the inbox 

15 server 270 by making requests to the inbox proxy 270 f . 

The proxy, generally waits for a request from an 
application and then services the request. 

The inbox proxy's main responsibility is to 
process requests by either handling them internally 

20 within the inbox proxy 270' or forwarding them to the 

inbox server 270, and then responding back to the 
client (i.e., the fulfilling servers in this case). In 
order to maintain secure connectivity throughout the 
system, the inbox proxy 270', uses the application 

25 program interfaces (APIs) provided by the "networkMCI 

Interact" supporting different types of data transport 
mechanisms: synchronous transaction; asynchronous 
transaction; and, synchronous bulk transfer. The 
transport mechanisms are implemented as sockets message 

30 protocol, and the proxy handles its conversation 

processing on a thread or process per conversation 
basis for servicing multiple simultaneous clients. 

As an alternative to the transports above, 
the inbox server 270 offers direct File Transport 

35 Protocol (FTP) "put" for very large transfers in order 

to alleviate some of the network server loads. The 
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fulfilling servers 400, 500 with large data transfers 
typically use the common shareware compression format 
ZIP which is also PKZIP compatible. Alternately, the 
fulfilling servers 400, 500 distributing information 
via the inbox may "put" the data to the inbox and defer 
zipping until after the inbox receives the data. 

As described, the fulfilling servers, when 
placing the data in the inbox, notify the report 
manager server 250 they are adding new data in the 
inbox. The report manager 250 then retrieves and FTPs 
the appropriate metadata associated with the new data 
in the inbox, notifying the inbox of the new additions 
to the inbox, i.e., the new data and the associated 
metadata. The metadata is then stored in the inbox 
server database 273 along with the resort results. 
Thus, if the metadata is required to be changed, it 
does not interfere with the information needed to 
display the reports included in the inbox. 

Particularly, as shown in Figure 16, the 
Inbox server 270 interface with the Inbox Client 210 
supports messaging that enables the User to remove an 
item from the Inbox e.g., delete a report, or, to 
delete all items from the Inbox, e.g., for a particular 
Enterprise and User ID as well as other associated 
reports. The parameters used in the metadata messaging 
between the Inbox client and the Inbox server include, 
particularly, the List "L" message which is a 
synchronous request for a list of all Inbox items for a 
specific user. The Inbox fetch "F" function is a bulk 
transfer request that enables bulk transfer of the 
requested file to the Inbox client. 

Referring back to Figure 12(b), after editing 
or modifying an existing report, the user may simply 
select to save the report and exit. In this case, the 
ARD message is sent from the Report Requestor client to 
the RM server and is saved in the RM inventory database 
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for subsequent execution. Consequently, the report is 
flagged as incomplete in the User_table and may not be 
run until a run option for that report is chosen. 
Otherwise, the report may be immediately scheduled if 
the user selects the save and run button. 

As described, Metadata messaging is used 
throughout the various components the StarWRS system 
200. The format of an interface message that is sent 
to the Report Scheduler server is identical to the 
format as the interface messaging format returned by 
the RS server 260. Thus, in the case of automatic 
recurring reports, a variation of the process outlined 
in Figure 11(b) occurs at step 360, whereby the ARD 
request is instead sent from the report scheduler to 
the fulfilling server at the programmed frequency. 
Particularly, when a report is required to be run, the 
Report scheduler server 260 (Figure 10) sends an ARD 
request to the fulfilling server in a metadata message 
format having parameters. Upon processing of the 
metadata message, the fulfilling server will respond to 
the report Scheduler with an acknowledgment of the 
command, and the process outlined in Figures 11(b) and 
11(c) is executed. 

The Report Scheduler server 2 60 is 
additionally capable of updating the User_report status 
table and, preferably, is provided with a tracking 
mechanism for tracking the Scheduling of user reports. 
If the report is an Ad hoc report, it is marked as 
inactive in the user report table once the status is 
complete. 

StarODS 

As mentioned, the StarODS data management 
tool of the integrated suite of telecommunications 
network applications comprises a back-end architecture 
providing customers with priced reporting data 
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pertaining to usage of their telecommunications 
networks. 

In Figure 14 (a) , there is shown the high- 
level logical approach of the StarODS data management 
system 40 integrated with the StarWRS component 200 of 
the nMCI Interact architecture. Generally, the data 
management system 400 of the invention, referred to 
herein as "StarODS" , provides customers with priced 
reporting data pertaining to telecommunications 
services. Although the description herein pertains to 
priced billing data, it should be understood that the 
principles described herein could apply to any type of 
reporting data. Through StarWRS web -based reporting, 
the StarODS system provides priced reporting data and 
implements a DataMart approach for maintaining the data 
used for customer reporting. StarODS stores and 
incrementally processes customer's priced data included 
in call detail records, and loads this processed data 
in Data Marts. From these data marts customer's priced 
reporting data may be provided to customers on a daily 
basis via the StarWRS reporting system. 

For priced reporting data, report categories 
from which a variety of reports can be generated 
include: a) Financial category - for providing priced 
data reports relating to longest calls, most expensive 
calls, Off Peak Calls, payphone report, usage summary, 
calling card summary, and area code summary for Toll 
Free, VNET, Vision, and CVNS customers; b) Marketing 
category - for providing priced data reports relating 
to country code summary, state summary, frequent 
numbers, frequent area code summary, frequent state, 
and frequent cities; c) Telecommunications category - 
for providing priced data reports relating to call 
duration summary, IDACC/Supp Code Summary and Call 
Access Summary for Toll Free, VNET, Vision, CVNS 
customers; d) Call Center report category- for 
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providing priced data reports relating to most active 
toll free numbers, Hourly Distribution, Day of Week 
Distributions, state summary, and country code summary 
for their Toll Free, VNET, Vision, CVNS customers; e) 
Monitor Usage - for providing priced data reports 
relating to longest calls, most expensive calls, most 
active calling card and most active toll free numbers 
for their Toll Free, VNET, Vision, CVNS customers; f) 
Analyze Traffic - area code summary, country code 
summary, state summary, range summary, city summary, 
frequent numbers, payphofte report, usage summary, 
calling card summary, IDACC/Supp Code Summary, Day of 
Week Distributions, Hourly Distribution, Call Access 
Summary and review calls; and, a g) Check Calling 
Frequencies category - for reporting on frequent 
numbers, frequent area code, frequent country codes, 
frequent state and frequent cities. 

Figure 14 (a) illustrates the primary 
components implemented in the StarODS priced reporting 
data management component 400. As shown in Figure 
14(a), a first traffic feed 405 provides raw call 
detail records from external network switches, 
translates and sorts the data into billable records for 
input into two systems: a Commercial Billing system 
("NCBS" ) mainframe server process 410 for pricing the 
records at tariff for customers subscribing to, e.g., 
MCI's VNET and Vision telecommunications products; and, 
a toll-free billing server process 420 for pricing the 
records at tariff for customers subscribing to 
toll-free telecommunications products. A common data 
gateway component 430 including a mainframe extract 
process 435 and a data harvesting process 440 receives 
these inputs on both a daily and monthly basis for 
processing. Particularly, the mainframe extract 
process 435 creates a selection table including all 
subscribing customers, compresses files for 
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transmissions and extracts priced reporting records 
from the runstreams. The harvesting process 440 is 
responsible for performing data validations, filtering, 
data translations, data grouping, data routing, and 
data logging functions. According to a dimension table 
based on data within selected BDRs, the harvesting 
process applies business rules to the data, cleanses 
the data, transforms the data, creates load files for 
DataMarts and compresses files for storage in the 
DataMarts. The harvesting component 440 may 
additionally perform an aggregation function for 
supporting long term storage and rapid access of data 
for customer reporting, and performs trigger 
actions/events based on predefined criteria. 

Additionally, as shown in the Figure 14 (a) , 
other external systems and applications may interface 
with the common data gateway component 430 including: 
Cyclone Billing system 422a and Concert Virtual Network 
Services 422b which provide additional billing detail 
records; and, a calling area database 425 which 
provides geographical reference information, i.e., 
identify city, state and country information. 

After the data has been processed in the 
Harvesting component 44 0 it is input to an Operational 
Data Store component ("ODS") 450 that stores the 
billing detail records and dimension tables as a data 
model. This ODS layer 450 is comprised of all data 
harvested from all applications in the data harvesting 
layer 430, and feeds report- supporting DataMarts 470 in 
a manner which supports customized data access. The 
Datamarts may be engineered to pre-process data, create 
aggregates, and otherwise perform transformations on 
the data prior to DataMart loading 465 in order to 
implement a defined data model, e.g., star schema key 
structures, fact and dimension tables depicted as block 
460. In the preferred embodiment, as shown in Figure 
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14(a), the ODS 450 includes multiple datamarts 470 each 
for storing and retrieving daily and monthly priced 
data on a periodic basis. It primarily is responsible 
for hosting highly current data, typically at least 72 
hours old. In accordance with customer -reporting 
needs, data marts 470 are partitioned in accordance 
with partitioning schemes which, in the invention, is 
based on customer- ID. Particularly, each DataMart is 
engineered for servicing specific customers or specific 
product sets, as well as engineered for the specific 
requirements of the customer /product such as high 
insert activity, heavy reporting requirements, etc. As 
data is volatile and changing and may not produce 
consistent results for the same query launched at 
multiple times, ODS is engineered for high performance 
through appropriate storage technologies and parallel 
processing: Although not shown, a common data warehouse 
is provided in this ODS layer that is responsible for 
performing storage, retrieval and archiving of data, 
typically of relaxed currency (e.g., more than 24 
hours) and is targeted at trend analysis and detection. 
In the preferred embodiment, the datamarts utilize an 
Informix database in a star topology. 

As described herein, from the data included 
in these data marts, one-time or recurring priced data 
reports are available for reporting through the NMCI 
Interact StarWRS reporting system 200. 

Additionally, the ODS component 450 includes 
a Decision Support Server ("DSS") reporting engine 
component 475 that performs the following functions: 1) 
receives various customer report requests from the 
StarWRS GUI Report Requestor component and accordingly 
generates database queries; 2) routes the query to the 
appropriate data marts 470, data warehouse or 
operational data store; and, 3) responds to the 
requestor with a formatted result set. The DSS server 
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475 may also perform cost estimation, agent scheduling, 
workflow broadcasting interface, and transaction 
logging functions. In the preferred embodiment, the 
DSS 475 is a cluster of DEC (Digital Equipment Corp.) 
UNIX 8400 servers running Information Advantage® 
software accessing an Informix database, e.g. , Informix 
Dynamic Server V.7.3. database product, distributed 
across multiple Data Marts. 

In accordance with the invention, the primary 
function of the DSS 475 is to generate priced billing 
report data in accordance with the customer's request 
which is received from the StarWRS reporting component 
as a metadata message. To accomplish this, the DSS 
interfaces with two StarWRS systems: Report 
Manager/ Scheduler 250, and Inbox 27 0, as shown in 
Figure 14(a). As described herein, the Report 
Manager/ Scheduler formats the customer's request in 
accordance with a defined set of rules and sends a 
metadata request message to the DSS. The DSS 475 reads 
the customer's metadata descriptions of the type of 
priced data report requested by a customer, translates 
the metadata into database queries, and implements 
commercial off-the-shelf ("COTS") tools such as 
Information Advantage's Decision Suite™ to generate SQL 
queries, and run the queries against the data in the 
DataMarts. Afterwards, the query results are formatted 
by a formatter process into a form readable by StarWRS 
report viewing components, and the completed reports 
are transmitted to the directory of the customer's 
Inbox, e.g., via FTP. 

In the preferred embodiment, a publish- and - 
subscribe communications tool 350 such as Talarian 
SmartSockets™ messaging middleware is used to 
coordinate report requests transmitted from the StarWRS 
report Manager to DSS, and report completion 
notification from DSS to the StarWRS Report Manager. 
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The Report Manager formats the customer's request in 
accordance to a defined set of rules and sends the 
request to the DSS as a Talarian message with the 
Report Manager 250 maintaining the Talarian Sender 
program, and the Decision Support Server 475 
maintaining the Talarian Receiver program. Messages 
are sent with guaranteed message delivery ("GMD"), thus 
assuring all request data sent by RM is received by the 
DSS. As known, Talarian messaging middleware defines a 
message as types and subjects. A message 
type is a structure that defines the format of the 
message. Message subjects are subsets of message 
types and describe messages by which Talarian 
receivers can subscribe. Conversely, message subjects 
describe messages by which Talarian senders publish. 

In the application programming interface 
"API", the RM server 250 publishes the message to the 
Decision Support Server in response to its receipt of a 
report request. Similarly, a DSS/Inbox API is provided 
to manage FTP transmission of completed customer report 
files including: error handling, retry logic, and the 
ability to maintain the file name and location of where 
report files are stored. Particularly, the DSS/Inbox 
API sends the report file to the inbox (Figure 14(a)). 

In the preferred embodiment, the DSS 
architecture is transparent to the Report Manager which 
publishes Talarian messages to which the DSS will 
subscribe. More particularly, an RTServer process 
located in the RM is provided for maintaining 
connections, implementing a report request queue 490 
for ensuring guaranteed message delivery, and tracking 
the success of all messaging operations. In addition 
to the tokenized character string request message which 
specifies report type, filters, and any customer 
request -specific information, RM server provides 
additional fields as part of the Talarian request 
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message including: a Corp_ID, Priority, and RequestlD. 
Corp_ID allows the DSS to route the request to the 
appropriate data store without having to invoke a 
parser. Data are partitioned on Corp_ID in the ODS 
database warehouse. Requested is used to send back an 
ARDA failure message, in the event of an invalid 
message. The Priority field allows DSS to pickup the 
next high priority request from a queue of 
non- processed requests, without invoking the parser. 

Figure 14 (b) illustrates the implementation 
of an Information Advantage® Interface Object ("IAIO") 
472, which is a process running in the DSS 475 for 
performing the following functions: 1) publishes and 
subscribes Talarian messages to Report Scheduler; 2) 
parses the request metadata ARD (Add Report Definition) 
message received from the RS 260; 3) publishes an ARDA 
(Add Report Definition Acknowledgment) ; 4) populates a 
request table 493 with total, sub- total and sort 
information according to the received report request; 
5) transforms the ARD tokens from the metadata request 
into an overlay file 492 which is a text file that is 
submitted to IA's Decision Suite™ process to generate 
the corresponding SQLS; 6) updates a Request Status 
table 4941 with appropriate status, e.g., process 
complete, failed, in progress, etc.; and, 7) if a 
failure occurs, it updates an error log (not shown) . 

More particularly, in view of Figure 14 (b) , 
ARD metadata request messages are received into the ODS 
system via arbitrator processes which are responsible 
for routing the request message to the appropriate ODS 
database according to a Corp/ODS mapping table (not 
shown) . 

In Figure 14(b), a Talarian receiver, 
referred to herein as a Talarian Interface object 
("TIO") 350, is a process that receives the Talarian 
message, manages the GMD functionality, and posts 
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updates to the request table 493 and request status 
table 494. The ODS Request table 493 is the table - 
maintained for the purpose of holding specific report 
request information from the received ARD message, and, 
the Request Status table 494 tracks the status of DSS 
processes for the current request. As further shown in 
Figure 14(b), the receiver 350 inserts the message 
received from an arbitrator into the request table 493 
and request status table 494 along with the priority, 
timestamp and status fields. The request status table 
resides on the ODS database and the messages are stored 
in the queue to provide queuing, log and tolerance from 
the failures. To determine the pending messages to be 
processed, a status field and history_stat flags are 
used. 

As further shown in Figure 14 (b) , in 
operation, the Information Advantage® Interface Object 
("IAIO") 472 reads the status table 494 for new 
entries. When a new entry is posted, it invokes a 
parser process 495, for parsing the received report 
request ARD message, and generates an overlay text file 
492 comprising tokens corresponding to the requested 
report format and data descriptions. An SQL engine 
generator, e.g., Decision Suite™, receives the overlay 
file 492 and performs the following functions: 1) 
generates SQL; 2) submits the SQL to the appropriate 
datamart (ODS database); 3) generates a Report file 
with a *.txt extension; 4) updates Request Status table 
494 with appropriate status; and, 5) if a failure 
occurs, updates the error log. Following generation of 
the *txt file, a sort process is invoked to perform the 
following functions: 1) reads the Request table 39 0 for 
column (s) on which to sort the Report; 2) reads the 
*.txt file; 3) sorts the *.txt file and generates two 
files: i. a file with a *.hdr extension which file 
contains the header information, consisting only of 
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only column id's, and, ii. a file with a *.data 
extension which file contains sorted data provided in 
the *.txt file and is the body of the report; 4) it 
further updates the request status table with a 
5 'success' or 'failure' code; and, 5) if a failure 

occurs, updates the error log. 

Continuously running FTP, NRL and ARDA 
processes are provided to take appropriate actions in 
accordance with the entries in the request status table 

10 494. For example, an FTP process performs the 

following functions: 1) reads the status table 493 for 
entries ready to be sent to the Inbox and FTP'S the 
.csv or txt to the inbox 270; 2) Determines success or 
failure of file transfer; 3) Updates the Request Status 

15 table 494; and, if a failure occurs, updates an error 

log. The NRL (Notification of Report Location) process 
performs the following functions: 1) reads the Request 
Status table 494 for any success status or failure of 
any process; 2) Invokes a receiver process with 

20 appropriate status and file location populated in the 

NRL; and, 3) If failure occurs, updates the error 
log. The end- to -end process 600 from a priced report 
request to report delivery is shown in Figures 15(a) - 
15 c) . 

25 Assuming successful user logon and 

authentication, as described herein, the first step 602 
of Figure 15(a), indicates that a user has opened the 
report requestor dialog box from the NMCI Interact home 
page (Figure 5 (a) ) by selecting the Report Requestor 

30 icon 83. 

Using metadata messaging, the StarWRS Report 
Requestor retrieves an available report list (including 
user defined list) from StarWRS Report Manager, as 
indicated at step 605. This process entails invoking a 
35 Communication Manager object to communicate with the RM 
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server in order to obtain a SURL metadata message, as 
described. 

Next, as indicated at step 610, the Report 
inventory for the specific user is loaded and displayed 
5 for the user on the user report request display screen, 

enabling the user to select a report, as indicated at 
step 612. Then, at step 615, the selected report is 
retrieved from StarWRS Report Manager and displayed in 
the manner as described. 

10 Then, as indicated at steps 618 and 620, the 

user selects a product, including phone numbers and 
geographic locations, etc. and enters criteria, i.e., 
reporting interval and frequency, if a new report is 
desired. Specifically, when the user selects a report 

15 from the Inventory List or a new report, an WRSEdit 

Screen is launched to provide the editing capabilities 
which are available for the Report format, as 
described. 

Once a report is created the user may save 

20 the report request, e.g., by clicking a "Save and Exit" 

button, or submit the request, as indicated at step 
625, e.g., by clicking a "Save and Run" button. When a 
report is submitted the selected report type and 
reporting criteria are sent to the Report Manager. As 

25 indicated at step 628, the RM creates the metadata 

request for which the DSS has a predefined interface. 
The metadata request is submitted by StarWRS Report 
Requestor to a COTS software module, e.g., such as 
provided by Information Advantage® which module is 

30 used for the generation and execution of SQL queries 

and retrieval and formatting of the results. 
Particularly, the metatdata requests are transmitted 
via an interface with the Talarian Smart Sockets 
product and a header is built for each report request 

35 including the CorpID and Enterprise information which 

is used by the IAIO to select the proper DataMart as 
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the target for the query. At this time, the report 
requestor additionally creates an entry in a RM table 
to track the progress of the request. RM communicates 
with the StarODS using Talarian Smart Sockets® which 
creates a header comprising the product and other 
information, and controls the delivery of the report 
request. Smart Sockets guaranteed messaging feature 
automatically routes the call and repeatedly tries 
until the delivery is successful. 

Next, as indicated at steps 630 and 632, the 
DSS receives the request and acknowledges receipt. 
Specifically, when the request is received it is first 
validated with StarOE to ensure that the user is 
entitled to receive information about the selected 
product corp and number (s) . Once the request passes 
validation, the DSS IAIO reads the header to determine 
which Data Mart will ultimately be queried. It then 
parses the metadata into a format which the COTS 
software can readily convert into an SQL statement, as 
indicated at step 635, Figure 15(b), and adds the 
report to the DSS report queue based upon type (Daily, 
Weekly, Monthly, Adhoc) and associated DataMart, as 
indicated at step 638. It should be understood that at 
this point, the request has been flagged as submitted 
in the RM database, as indicated at step 633. 

From this point forward, DSS activity is 
controlled by a control process and progress or errors 
are logged internally in the DSS system. This control 
process includes logic enabling the prioritization of 
report requests and application of rules defining the 
order in which they should be executed. Thus, at the 
appropriate time, depending on the type or report, 
reporting period and other parameters, the Information 
Advantage query engine selects the report from the 
queue, as indicated at step 640, which action is logged 
in the report status table (Appendix I) as indicated at 
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step 642. The SQL statement is then built by Decision 
Suite™ and routed to the appropriate data mart for . 
execution in the manner as described herein, as 
indicated at step 643. The query engine generates the 
5 SQL statement from the metadata and executes the report 

which action is logged in the report status table as 
indicated at step 645. Next, as indicated at step 648, 
the query results are returned, and, a post -SQL 
formatting process is invoked. 

10 More particularly, the report result set from 

Decision Suite is input to a Formatter module which 
performs various report result transformations 
including: 1) Converting of column headers generated by 
Information® Advantage) into appropriate column ids 

15 that are recognizable to the StarWRS client viewer 

functionality (as indicated at step 650); 2) Provide 
subtotaling or specific requested "subtotal by" columns 
in the format required by the StarWRS client interface 
(as indicated at step 653) and provides report -based 

20 totals as requested by customer; 3) converting binary 

stream data file to ASCII text file (as indicated at 
step 655); 4) implementing Replace logic, e.g., 
replacement of "TAB" delimiters with appropriate 
"Comma" field delimiters (as indicated at step 657) ; 5) 

25 implementing Repeat /Padding logic, i.e., identifying 

compressed columns/values and decompressing (or 
repeating) the values that were compressed; 6) 
providing alphanumeric translations for any encoded 
data elements returned in the result set data file (as 

30 indicated at step 659); and, 7) adding new 

computed/derived columns, e.g., percents, averages of 
column data values, etc., as requested by customers on 
specific reports. 

After formatting the report, as indicated at 

35 step 660, a message is sent to the control process to 

update the request status table 494 (Figure - 14 (b) ) . It 



-90- 



WO 99/15979 



PCT/US98/20170 



should be understood that, if a failure occurs during 
formatting, the error log is updated and a status 
message sent to the request status table 494, as well. 
Then, as indicated at step 665 (Figure 15(c)), the 
formatter creates a *.csv (Comma Separated Value) or 
txt file, gives the file a unique name and saves the 
file. Preferably, a *.csv is the file generated if the 
report is successfully generated. As indicated at step 
668, the *.csv report/data file is then "pushed", 
implementing FTP, to the StarODS server's directory on 
the Inbox server 270. 

Finally, as indicated at step 670, once the 
file has been successfully transferred to the Priced 
reporting director on the Inbox server, and the request 
status table 494 appropriately updated at step 675a, an 
NRL message is sent to the RM Server 250 notifying it 
of the report file name and location in the Inbox, 
requestor information, and if the transfer was 
successful. This is accomplished by using a "NRL" 
metadata message with a corresponding NRLA message sent 
back to the DSS. Report Manager is subsequently 
notified of the successful completion of the report and 
the report request is marked as completed in the RM 
database. If the report is a recurring report, it is 
not marked as complete. After the control process 
updates the report status table, the Report Manager is 
notified that the report is complete and the Inbox 
server notifies the user that report is ready. 

A user may subsequently retrieve the report 
by clicking on the message center icon 81 from the home 
page of Figure 5(a) which will present to the customer 
a list of all the available reports. To view a report 
the user selects the report and, the report metadata 
and the appropriate viewer are downloaded to the user 
( cl ient ) works tat ion . 
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TVS 

As mentioned, the traffic view system ("TVS") 
500 of the present invention comprises a Traffic View 
Server 550 which functions to store network call detail 
records (CDRs) and statistics, generate reports and 
deliver reports and/or call detail to the customer via 
the StarWRS Web Reporting System, and supplies on-line 
customer access to call detail and hourly statistics 
that aid the customer in Network management, call 
center management and customer calling pattern 
analysis. For real time (unpriced) data, statistics 
are generated for the following totals: minutes, 
attempts, completes, incompletes, other, dto (direct 
termination overflow), short calls, didn't wait, didn't 
answer, tec, and equipment failures. 

The process by which the TVS server 550 gets 
data is now explained in greater detail with reference 
to Figures 18 and 19, As shown, call records are 
created by a network switch 501. An AP (Adjunct 
processor) or Storage and Verification Elements 
("SAVE") platform 502 is co- located with each switch 
and receives all the call records from the switch as 
soon as possible after a call disconnects. The AP/SAVE 
sends all the call records to a- (Network Information 
Concentrator (NIC) 503 where records are grouped 
together and those groupings numbered for a more 
efficient network utilization.. If the NIC determines 
that it is missing a gap in the numbers, it will 
request the AP/SAVE resend that group of data to ensure 
that no data is lost. Should the NIC be unavailable to 
receive data, the AP/SAVE queues the data for later 
delivery. The NIC 503 receives all calls from all 
switches as soon as possible after a call has 
disconnected (hangs up) and distributes records to 
clients that match a certain criteria. 
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A generalized statistics engine (GSE) 
component 504 receives all records that are considered 
to be a toll free (800/8xx, etc) call from the NIC and 
also employs the same sequencing of groups of records 
5 to ensure that no data is lost. Should the GSE be 

unavailable, the NIC will queue the data for later 
delivery. The GSE component 504 further filters toll- 
free calls to only process calls that match a 
subscriber list which is maintained by an order entry 

10 OE process on the GSE (not shown) that accepts add & 

delete requests from TVS via a messaging interface 507 
as shown in Figure 18. The GSE component, then formats 
the CDRs, i.e., enhances the call records, from the 
form as originally provided at the switch, into a 

15 normalized form to allow for a common record format 

regardless of the type of switch that created the 
record, or the exact call record type. For example, 
different network switches generate different calm 
detail records, e.g., call detail record, enhanced call 

20 detail records, etc., which denote differences in toll- 

free services and features. This type of call detail 
record generated by GSE component is herein referred to 
as a TCR (Translated Call Record) . 

Groups of TCRs are sent from the GSE to TVS 

25 via TCP/IP. When TVS has safely stored that record it 

sends an acknowledgment to the GSE 504 so that the GSE 
may dispose oi; the group. Should TVS not be available 
to receive data, GSE queues data to be sent later. 

As shown in Figure 18, in the preferred 

30 embodiment, initial customer provisioning occurs at 

either the Corporate Order Entry system 223 (CORE) or 
the StarOE server 285 component of MCI Interact. 
Particularly, CORE 223 transmits daily to the TVS 
server 550 via Network Data Mover (NDM) files which 

35 comprise information about new reports for TVS to 

create, and where to send those reports, e.g., FAX, E- 
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Mail, or US Mail. In the NMCI Interact TrafficView 
Server 550, a CORE FEED process 523 provisions reports 
into a reference database 551, and sets up scheduled 
reports to work on the next boundary, e.g., hourly, 
daily reports at midnight the next complete day, weekly 
reports at the end of the next day, monthly reports at 
the end of the month, etc. If this report requires 
Call detail records, as opposed to aggregated data, a 
CDR database is selected based on weighted values for 
the existing database. If a request contains a toll- 
free number that has not been provisioned with the GSE, 
a request is sent to the GSE to start collecting that 
toll-free number. This request is sent by placing a 
request onto a DMQ queue 553, and a GSE_SEND_QE process 
554 is invoked to forward the request to the GSE 504 
via a TCP/IP interface. 

As further shown in Figures 18 and 20, in the 
preferred embodiment, requests to enable TrafficView 
customers are received in real-time from StarOE 285 via 
TCP/IP. Generally, StarOE specifies what general 
categories of reports can be requested for a given nMCI 
Interact subscriber. These categories include: 
1) reports that only require data aggregation; 2) 
reports that require call detail records to be 
collected; and 3) real-time monitor (RTM) reports. 
This is provisioned into the reference database* 551 for 
future verification of requests from the nMCI Interact 
platform. If a request contains a toll-free number 
that has not been provisioned with the GSE, a 
subscription request is sent to the GSE 504 to start 
collecting TrafficView data pertaining to that tollfree 
number. This request is sent by placing a request onto 
the DMQ queue 553, and the GSE_SEND_OE process 554 then 
forwards this request to the GSE 504 via a TCP/IP 
interface. In the preferred embodiment, the content 
and format of an "order entry" message generated by the 
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TVS server for requesting unpriced traffic data from 
the GSE is provided in Appendix H. In accordance with 
this messaging, the GSE selects all TCR's for TVS 
enabled customers and places them in a SAVE storage 
queue, e.g., Versant or Talarian, for subsequent 
distribution to the TVS server. 

As further shown in Figure 18, an input feed 
from the calling area database component 508 ( " C ADB w ) 
provides the TVS server 550 with reference data 
including state and country information for mapping 
NPA/NXX (Numbering Plan Area/ Number Exchange) to city 
name and state code, and, for mapping country codes to 
country names. Data is transported from the CADB 
database 518 to the TVS server via a network data mover 
("NDM") or FTP via interface 519. 

A further input feed from the Global 
Information Repository lf GIR !t component 511 provides the 
TVS server with International toll-free number 
terminations on a periodic basis. 

From the circuit order management system 
("COMS") component 515, TVS receives three NDM feeds: 
1) a Trunk Type Master feed 516 used in Un- priced 
Reporting to map enhanced voice service/dedicated 
access line (EVS/DAL) information to specific service 
locations; 2) an automatic number identification 
( "ANI" ) feed 517 also used in Unpriced Reporting to map 
EVS/DAL information to specific service locations; and, 
3) a switch mapping feed 518 to map the switch ID (per 
Network control system) to the billing representations 
of the same switch. 

As further shown in the Fig. 18, unpriced 
data collection process begins with the placement of an 
order for unpriced reporting with the customer's 
account team. Specifically, the account team places 
the order in real time using an ordering system 
component. In a periodic process, this order 
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information is transmitted to OEHubs 224, e.g., via e- 
mail which later inputs the necessary service and 
reporting flags to the StarOE component 285, via 
messaging interface 226. The OEHubs 224 further adds 
new customers to the corporate order entry ("CORE") 
system component 223, which provides customer billing 
hierarchy information used by the StarWRS system. The 
new customer hierarchy information is extracted by the 
CORE system 223, and is available for pickup by the 
StarOE server 285 via messaging interface 227. The 
StarOE server 285 then messages the Traffic View Server 
550 in real time via TCP/IP that the number has 
been added for Unpriced Reporting. The TVS 
additionally messages the GSE component 505 in real 
time to immediately initiate the collection of call 
detail for that number, as will be described in greater 
detail herein. Due to latency inherent in the 
fulfillment process, customers may select and receive 
daily reports after CDR collection begins. 

In accordance with the invention, a wide 
variety of reports and reporting frequencies are 
available. In the preferred embodiment, reports are 
available in hourly, daily, weekly, and monthly 
frequencies. Types of TVS reports that are available 
to customers include: Standard reports; Summary 
reports; Termination Reports; Exception reports; and, 
unpriced call detail. For example, Standard reports 
that may be generated from stored Toll Free hourly 
statistics include, but are not limited to: Summary by 
Toll Free Number and Hour which is available in the 
following frequencies (Ad-hoc "A", Daily "D" , Weekly 
"W" , and Monthly "IM"); Summary by Toll Free Number and 
Date (A,D,W,M) ; Summary by Toll Free Number and day of 
week ("DOW") (A,W,M); Summary by Toll Free Number and 
Week (A,M) ; Summary by Toll Free Number and NPA 
(A,D,W,M); Summary by Toll Free Number, Service 



WO 99/15979 



PCT/US98/20170 



Location and Hour (A,D, W,M) ; Summary by Toll Free 
Number, Service Location and Date (A,D,W,M) ; Summary by 
Toll Free Number, Service Location and DOW (A,W,M; 
Summary by Toll Free Number, Service Location and Week 
(A,M) ; Summary by Service Location and Hour (A,D,W,M); 
Summary by Service Location and Date (A,D,W,M); Summary 
by Service Location and DOW (A,W,M) ; Summary by Service 
Location and Week (A,M) ; Summary by Service Location, 
Toll Free Number and Hour (A,D,W,M) ; Summary by Service 
Location, Toll Free Number and Date (A,D,W,M) ; Summary 
by Service Location, Toll Free Number and DOW (A,W,M) ; 
Summary by Service Location, Toll Free Number and Week 
(A,M) . The Toll Free Summary Reports generally 
comprise three sections: Summary, Incomplete Call 
Analysis, and Network Customer Blocked Analysis (other 
category breakdown) . The Termination summaries include 
three types of termination reports: Toll Free by 
Location, i.e., showing termination summary and 
incomplete call analysis by service location for a 
specific Toll Free number; By Location, i.e., by 
service location across all Toll Free numbers 
terminating to the same service location; and, Location 
by Toll Free, i.e., for a specific service location, 
shows each Toll Free number terminating to this 
location. The originating NPA/Country Code summary 
reports provide information by NPA and Country for each 
Toll Free number attached to the report. 

Additionally available are what are called 
Call Detail Exception Reports /images which provide 
reporting information pertaining to the following: 
Completion Rate and Retry (A,D,W,M) ; Completion Rate 
and Retry with Queue Abandonment (A,D,W,M) ; Lost Caller 
and Retry (A,D,M) ; Lost Caller and Retry with Queue 
Abandonment (A,D,M) ; Most Frequent Calling Numbers 
(A,D,W,M); Most Frequent Calling NPA/NXX (A,D,W,M) ; 
Most Frequent Calling Country (A,D,W,M) . 
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The nMCI Interact Exception reports (images) 
includes: Completion Rate and Retry (A, D,W,M) ; 
Completion Rate and Retry with Queue Abandonment 
(A,D,W,M) ; Lost Caller and Retry (A,D,M) ; Lost Caller 
and Retry with Queue Abandonment (A,D,M) ; Most Frequent 
Calling Numbers (A,D,W,M) ; Most Frequent Calling 
NPA/NXX (A,D,W,M); and, Most Frequent Calling Country 
(A,D,W,M) . The nMCI Interact Exception reports (data) 
includes: Call Detail by Originating ANI (A,D,W,M); 
Call Detail by ID Code (A,D,W,M) ; Call Detail by NCR 
Indicator (A,D,W,M); Call Detail by Originating State 
(A,D,W,M); Call Detail by Disposition (A,D,W,M) ; Call 
Detail by Service Location (A,D,W,M); Payphone Summary 
(A,M) . Downloadable NMCI interact Call Detail reports 
includes Traffic view call detail (available as ad-hoc 
and daily) and Outbound traffic view call detail data 
(available as ad -hoc, daily and weekly) . 

As mentioned, via TCP/IP messaging, the TVS • 
system 550 receives a request in real-time from the 
NMCI Interact StarOE component 285 to be in collecting 
call detail records for a particular TVS/Unpriced 
reporting customer, which number had been previously 
assigned during the order entry process. When a 
customer discontinues Unpriced Reporting for a number, 
this information is entered in StarOE tables where it 
is stored for a predetermined period subsequent to 
termination of the number. After the predetermined 
period of time, e.g., seven days, the numbers scheduled 
for service deletion are passed to TVS via TCP/IP 
connectivity in real time. After receiving this 
information, TVS instructs the GSE 504 in real time to 
stop collecting CDRs for these numbers. 

Figure 21 illustrates a generalized block 
diagram detailing the internal TVS data acquisition 
processes. As shown in Figure 21, a TVS server 
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"GSE_TCR_RCVR» process 564 receives a group of TCR 
records from the GSE component 504. The GSE_TCR_RCVR 
process 564 inserts that group into a DMQ 
(DecMessageQueue) queue 553a that provides a guaranteed 
message delivery. Upon successful storing of a record 
into the DMQ queue 553a, the GSE_TCR_RCVR process 564 
sends an acknowledgment to the GSE component 504 so 
that it may delete that group. If TVS fails to 
acknowledge this group after a predetermined timeframe, 
the GSE continues to resend this group until an 
acknowledgment is received. The TCR^DISTRIB process 
566 reads groupings of records and distributes a record 
based on the toll-free number associated with that 
record in the following manner: 

First, as the reference database 551 contains 
information on which toll-free number belongs in which 
CDR database associated with the TVS server, records 
are grouped for each CDR database 561a, 561b; . . , 561n, 
to which they belong. The reference database 551 
additionally flags which numbers are to have statistics 
collected for them. Thus, an additional group of 
records is created and may be routed to a DMQ Queue 
553b which inputs these records into a statistics 
"stats" counter process 570 for statistics processing, 
as will be described in greater detail herein. When 
all the records in the group have been read, each group 
is written to it's DMQ queue 554a, 554b,.., 554n 
associated with its destination database CDR Database 
561a, 561b, . . , 561n. For instance via a TCR Poster 
process 555a, records destined for CDR database 561a 
are forwarded from the DMQ Queue 554a. Particularly, 
each CDR poster process 555a, 555b,.., 555n reads data 
from it's corresponding DMQ Queue and formats & stores 
those records in their database. 

With further regard to the stats counter 570 
shown in Figure 21, TCRs are rolled up into statistics 
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records. Specifically, the stats counter 570 keeps 
counts of the following: summary information about each 
toll free number for an hour; summary information about 
each toll free number and termination for an hour; and/ 
5 summary information about each toll free number and 

origination NPA for an hour. These statistics are kept 
in memory for a pre -determined amount of time, e.g., 
one hour. As matching records come in, statistics are 
updated. At the end of the time period, these records 

10 are written to the statistics database 571, and 

particularly high speed electronic data drives. 

The statistics that are gathered for each 
subscriber's toll-free number in the TVS system of the 
invention include: total completions, total call 

15 duration, total attempts, total switch control call, 

total Network Control System (NCS) blocked, total NCS 
rejected, total network blocked (all routes busy) , 
total supp code blocked, and out -of -band blocked. 

Additionally, statistics gathered for NP 

20 table procession include: originating NPA, total 

attempts per NPA, total calls completed (tec) per NPA, 
total call not delivered (blocked) per NPA, total 
attempts for International Originations, tec for 
International Originations ( M IO") , total calls not 

25 delivered (blocked) for 10. 

Additionally, call statistics for 
terminations include: termination type, termination 
address, total completions, total call duration, and 
call dispositions indicating the cause of an incomplete 

30 call including: total short calls, total didn f t write, 

and total didn't answer. 

With more particularity regarding the 
statistics database design, and, in further view of 
Figure 21, the stats_ counter 570 contains processes 

35 that read TCR's from a DMQ queue, and create statistics 
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records for input to "C_tables" in the statistics 
database 571. 

The algorithms implemented in TVS 
stats_counter process 570 for generating statistics 
data tables so that TCR records may be processed in 
batches include: a summary table process which process 
generates statistics for call summary data; a NPA table 
process; Country table process and Termination table 
process. The stats_counter 570 enables multiple 
processes to be run at the same time on the same 
machine. To allow an arbitrary number of Stats_Counter 
processes, the stats databases are organized as a 
series of configurable tables, e.g., ,f C_Tables" 572, 
which are temporary tables that the stats counters 
first insert records to. These tables are identical to 
normal statistics tables with the exception that they 
include a field for the date in them. In accordance 
with the provision of C_tables, a pending_stats_JList 
table and stats_table usage_list table are used to keep 
track of what data is in the C_tables, and to drive the 
movement of data from the C_tables to a more permanent 
database tables 574. 

Particularly, when the stats_counter process 
570 starts, it performs a check of the set of 
"CLtables" by inserting its process name in the 
used_by_process field of the stats_table_usage_list 
table. If the stats_counter process unexpectantly 
dies, it reclaims the tables previously used by 
searching the stats_table_usage_list for tables marked 
with it f s process name. The stats_counter process adds 
an entry into the pending_stats_list every time it 
creates stats for a new day. The usage_flag is 
initially set to "1" in that table. At the top of the 
hour, for example, the stats_counter processes marks 
all of the usage_flag entries to "2", and modifies the 
value of the used__by_process field in the 
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stats_table_usage_list to "MOVER 11 . The stats counter 
process then searches the stats_table _usage_list for 
another set of tables to use for the next hours 
counting. If the stats_counter process cannot find a 
set of tables, it aborts. To avoid this, there is 
extra sets of "c_tables" configured with entries in 
stable_usage_list . 

An example pending_stats_list table comprises 
a directory of what the stats -counter is working on, or 
finished with. Each record represents a name of a 
citable that contains statistics, and dates that are 
contained in this citable. The report generator 
process, and on-line access use this table to determine 
if there is any data in the c_tables that they may be 
interested in, and what the table name is. The 
Stats_counter processes insert records into this table, 
and data mover processes 573, shown in Figure 21, 
remove entries from this table. 

An example stats_table_usage_JList table 
comprises a list of all the eatables that are 
configured and used by the stats__counter processes and 
data_ mover processes to allocate tables amongst 
themselves. The number of records in this table remains 
static. Stats_counter processes 570 update the 
"used_by_process" field with their process name when 
they are in control of that table. At the top of the 
hour, they may change the used_by_process to "MOVER", 
and attempt to find another table, that is unallocated. 
The movers change the used__by_process name to "NONE" 
when they have completed moving data from that c table. 
In the preferred embodiment, there are four types of 
movers are currently configured to run: NPA, summary, 
country, and termination. Each type of mover looks in 
the pending_stats_list for the name of the "citable" of 
the same type with a usage_flag of "2", for instance, 
and the earliest date. The mover then transfers the 
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data for this date from the 11 citable" to appropriate 
the permanent table. When the data transfer is 
finished, the matching record in pending_stats_list is 
deleted. If there are no more entries for this 
"c_table" in pending_stats_list , the mover process 
takes the precautionary step of searching the "c__table ,f 
for additional data that was not noted in 
pending_stats_list . Entries are then added to 
pending_stats__list for any data found in the "c_table" . 
If no additional data is found, used__by__process in 
stats_table_ usage list is changed from "MOVER" to 
"NONE" for this "c_table". 

The interaction between StarWRS web -based 
reporting system and TVS system 550 will now be 
explained in greater detail with respect to Figure 22. 
In the preferred embodiment, reports may be triggered 
by two possible sources: Scheduled report setup by a 
CORE order; and, real time report requests as forwarded 
from the report request/Report Manager Server 250. The 
report generation process is hereinafter described with 
respect to real-time reports from the StarWRS system. 

As mentioned, requests are received in real- 
time from the Report Manager Server 250 which either 
passes on-demand reports from an end -user, or reports 
that it has internally scheduled via Report scheduler 
server 260. In the TVS server 550, a report manager 
proxy process 2501 1 gathers information about the 
reports to be generated from the reference database 551 
by determining whether the report request may be 
fulfilled by statistics processing, or the CDR's. If 
CDR's are needed, a determination is then made as to 
which database contains the necessary data. 
Additionally determined is whether the needed CDR data 
to fulfill the request spans a long period of time, 
e.g., several days. Once these determinations are 
made, the request is sent to the appropriate DMQ queue 
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554a, 554b, . . , 554n, or 553b via the report manager 
proxy process 250". 

For the scenario requiring generation of call 
detail data ("CDT") reports, i.e., those requiring Call 
detail records, the destination of the report, e.g., 
StarWRS Inbox server 270, fax, U.S. mail, etc., is 
determined from the reference database 551. Then, the 
requested data is gathered based on the metadata 
request, analyzed, and formatted by various 
corresponding report generation "CDT" processes 
indicated in Figure 11 as CDT process 559a,.., 559n. 
Although not shown in Figure 22, it should be 
understood that reference data that originates from 
CADB and COMS may be necessary to complete these 
reports. Furthermore, although not shown, the TVS 
server is provided with an additional set of queues and 
CDT processes for each of the CDR processing to allow 
longer reports to not interfere with shorter reports. 
If the requested report is destined for MCI Mail 
delivery (Fax, Mail, US Mail); then the data is 
formatted with headers, page breaks, line numbers into 
a report that is saved to a file. The report is then 
sent to an Internet Gateway 279, e.g., the MCI Mail 
Internet Gateway via SMTP for delivery by MCI Mail. 
Once the file is successfully sent it is deleted, thus 
allowing for report generation to continue when the MCI 
Mail Internet Gateway is not available. 

If the report is destined for the StarWRS 
Inbox server 270, the data is formatted in a comma 
separated value (CSV) format and sent to the Inbox via 
FTP. The Inbox is notified via TCP/IP that the report 
is complete by the inbox send process and that the 
appropriate metadata is available for report 
presentation via the report viewer. 

An identical process is implemented for those 
customer report requests for aggregate data, i.e., 
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statistics. However, the data that is gathered and 
analyzed is retrieved from a report generation process 
581 which retrieves the requested report data from the 
statistics database 571. 

As described herein, when the user requests 
call detail for a particular period of time, this 
request is translated by the StarWRS component into a 
metadata file which is sent to TVS in the manner 
described herein. Users schedule reports for execution 
using the Report Scheduler in StarWRS. When the user 
has completed report selection, modifications and 
scheduling, the StarWRS Report Scheduler component 260 
creates a metadata message comprising this information 
which file is passed to TVS in real time. The TVS then 
uses this file to formulate a query and runs the report 
for the scheduled time period. 

After TVS runs the report, TVS sends the 
report to the Inbox server component 27 0 of StarWRS 
immediately after they are completed. 

RTM 

As further shown in Figure 18, the NMCI 
Interact' s web -based front -end and middle- tier TVS 
system infrastructure 500 implements processes enabling 
customers to monitor in real time, their network 
traffic call detail statistics, in real time, via 
TCP/IP connections 293 and 294. As shown, customer 
requests are entered by the customer 100 via an RTM 
graphic user interface and preferably communicated over 
secure TCP/IP socket connections for input over the 
firewall 25 to at least one secure server, e.g., a DMZ 
RTM Web Server 52 (Figure 2) that provides for 
authentication, validation, and session management in 
the manner as described herein. 

Particularly, the user first establishes 
communication with the RTM Web server 52 (Figure 2), 
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Dispatcher and StarOE systems to enable logon, 
authentication and verification of Real Time traffic 
Monitor entitlements, as described above with respect 
to Figures 4-6. If the customer subscribes to Real 
5 Time Monitor, a Traffic Monitor icon 85 (Figure 5(a)) 

is automatically enabled when the home page appears. 

The process flow 700 for implementing real 
time monitoring of a customer's network traffic is 
shown in Figures 23 (a) -23(b). Preferably, as shown in 

10 Figure 23(a), in response to selecting the RTM 

function, at step 721, a hot link connection to the TVS 
CGI/HTML implementation of RTM is in order to initiate 
a second security/authentication process and verify the 
Unpriced data RTM products for which the customer is 

15 provisioned. With more particularity, the user 

connects to the RTM URL. and checks the RTM Web Server 
implementing an HTTP Post method. In response, the RTM 
Web Server generates a cookie and implements the RTM 
Web Server common gateway interface protocol ("CGI") to 

20 send a validation request to TVS via TCP/IP with the 

cookie. TVS server 550 validates the logon 
request by referencing Level of Service tables (not 
shown) provided in the Traffic View server that confirm 
the customer is enabled for RTM, as indicated at step 

25 729. The TVS server stores user information with the 

cookie, and returns the validation information to the 
Web Server. Next, via CGI, an HTML page is sent to the 
user as indicated at step 731 presenting the user with 
an RTM screen and menu options, as indicated at step 

30 735, thus allowing customer access to all RTM 

functionality which that user is entitled. As will be 
explained, this functionality includes interaction with 
the RTM application to formulate and transmit requests 
and receive the results. For example, the user may 

35 elect the tollfree numbers to be tracked, enter a 
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polling period, and define the call detail statistics 
desired. 

From an RTM window provided on a web -screen 
page, the customer is enabled to select or modify 
his/her predefined RTM use profile, as indicated at 
step 740, Figure 23(a). Specifically, the customer may 
create or edit their user profile, for example, by 
entering selection criteria such as: 800/8xx or Vnet 
number to report, a polling interval, and time zone. 
The user may also delete a user profile. The entered 
selection criteria may be saved by the subscriber as a 
new user profile for storage in the TVS server 
Level_of_use tables, as indicated at steps 744 and 745, 
or submitted directly to the TVS server, as indicated 
at steps 749 and 750. It should be understood that all 
TVS RTM functionality may be available to the customer. 
If, at step 740, the subscriber has selected a 
previously defined use profile, as indicated at step 
747, the subscriber may modify the profile, i.e., 
800/8xx or VNET number to report, polling interval, and 
define statistics, as indicated at step 748, and submit 
it directly to the TVS server, as indicated at steps 
749 and 750 (Figure 23(b)). 

At this point, the user can interact with the 
RTM application to formulate a request, transmit it and 
receive the results according to the user- selected 
tollfree number (s) to be tracked, polling period and 
defined statistics desired. 

Briefly, after receiving the request, at step 
752, Figure 223(b), the TVS formulates a query and 
submits the query to the call detail database which is 
the repository of all call detail records for the 
particular number selected. The TVS server selects the 
call detail data in accordance with the user profile or 
selection at step 754, and passes the data to the RTM 
Web Server which formats the data into an HTML table, 
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as indicated at step 756. This HTML table is sent to 
the user's browser at step 758 and the process 
continues at step 7 59 for each successive polling 
interval until the user terminates the request. 

Figure 24 is an illustration depicting the 
NMCI Interact RTM polling process. As shown in Figure 
24, the RTM system supports an HTML form "Post" or 
automatic refresh, to an active server page script. 
Thus, a Web page providing real-time unpriced call 
detail data has a timeout interval, e.g., one minute or 
greater, at which point the Web browser 20 will repost 
a request for data (HTTP Post) . The Post request is 
received by an Internet Information (web) Server 
("IIS") process 590 in the RTM server 52 that executes 
an active server page {".asp" ) script. This .asp script 
calls a DLL polling routine 593 via a communications 
(COM) interface. This polling DLL is a Visual C++ 
application running in the RTM Web server 52. Upon 
receipt of the timeout request, the DLL calls the TVS 
server 550 for real-time call detail data retrieval via 
TCP/IP message. Particularly, the call detail request 
is received by a RTM data retrieval process 59 5 
executing in the TVS server 550. Then, the real time 
data for each phone number (e.g., 800/8xx or VNET) is 
retrieved from the call detail database 598, which is 
the repository of real-time call detail data. The 
retrieved real time data is returned to the polling DLL 
process 593 and the current RTM output is formatted by 
the polling DLL and printed to the HTML page. The HTML 
page with the script embedded HTML is then communicated 
back to the Web Browser 20 via the IIS process 590. 

In view of the foregoing, a subscriber via a 
client workstation running a Web browser can monitor in 
real time, or, in addition, using the RTM system, has 
the ability to monitor in substantially real time, the 
operation of the network as it relates to the calls 
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directed to that subscriber's special service call 
number (s). For example, the subscriber may see in real 
time how many calms are being attempted minute by 
minute, how many calls are being allowed through the 
network, how many calls are incompletes, how many 
calls are blocked, etc. This ability to monitor the 
operation of the network gives the subscriber the 
ability to decide in real time the specific actions 
that need to be taken. For instance, if there is an 
abnormal number of incompletes for a given period, the 
subscriber can look at the specific call records that 
made up those incomplete calls. The subscriber may 
then request the management of the network to 
restructure the network so as to reroute the incoming 
calls of the subscriber to different locations where 
they may better be handled. 

Service Inquiry 

Another application of the suite of 
telecommunications network applications is the 
networkMCI Interact Service Inquiry ("SI") application 
which is a web -based network management product that 
enables customers to manage, i.e., create, status, and 
display service requests ("trouble tickets"), to the 
enterprise service provider (MCI) . Particularly, 
through a client application GUI, customers have the 
ability to create and query trouble tickets 
("tickets") . 

Figure 2 illustrates the service inquiry "SI" 
application server 36 interfacing with a backend 
Customer Service Management ("CSM") legacy host system 
40(a). The SI application server component 36 includes 
processes for handling all requests made of Service 
Inquiry by the customer (as relayed via the Dispatcher 
26) . Specifically, requests are handed off to Service 
Inquiry back-end processes and responses are received 
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from the Service Inquiry backend processes to be routed 
back through the Dispatcher to the client workstation 
web browser 20. 

As in any of the above -described suite of 
telecommunications network applications, the Service 
inquiry application utilizes the Common Objects 
application framework (COF) to inter -operate with the 
networkMCI Interact back plane and integrate with the 
other elements of the networkMCI Interact architecture* 
The Common objects framework is utilized to leverage 
existing infrastructure services such as logon and 
authentication, transaction management, and security. 
Particularly, the Service Inquiry application extends 
the COAppImpl class in order to inter - operate with the 
Interact back plane and other networkMCI Interact 
applications (as required) , and, includes one or more 
screens derived from the COAppFrame class. Most of the 
high level classes dealing with the initiation of 
transactions are utilized by Service Inquiry. The 
COClientSession class is available to the Service 
inquiry application upon successful login to the 
networkMCI Interact system and is utilized for session 
management (e.g., connect, disconnect, and logoff). 
The family of COTransaction classes is used to send and 
receive messages to the backend Service Inquiry 
service. These classes include CONonblockTransaction, 
COSynchTransaction, and COAsynchTransaction and, a 
COBulkTransaction may also be used if necessary. 
Additionally, the SI utilizes all of the 
COCommunications classes with the exception of the 
COBulkTransaction. However, as development and testing 
continues, the COBulkTransactions class may be 
utilized. 

Figure 25(a) illustrates the high-level 
design of the Service inquiry application 2200 
including the client application 2250 and server 2300 
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components. As shown, Service Inquiry requires 
integration with a number of external systems and 
utilizes the Common objects Framework for inter- 
application communications. Interfacing with the 
Service Inquiry application server 36 via the common 
objects framework are the StarOE server, e.g., for user 
profile information, as well as other Service Inquiry 
specific data, and, the CSM legacy host that provides 
the ability to query, status, and take action on 
service inquiries. Communication between the SI 
application server 36 and CSM 40(a) is via Registry 
middleware, such as described in commonly owned, co- 
pending U.S. Patent Application No. 08/560,550 
incorporated by reference herein. Figure 3 shows COF- 
based interapplication communication between Service 
Inquiry and StarOE. It should be understood that if an 
external system does not use the COF, Service Inquiry 
may utilize that system's API set and communication 
mechanism for inter -application communication. The 
above- referenced Registry system has a number of 
options for inter- application communication, including 
both Java and CORBA interfaces. 

The Service Inquiry communications and 
application server packages provide the framework for 
transporting client messages to the mid- tier 
application server for invocation of domain objects. 
The domain objects encapsulate the logic to translate 
the actual client messages and deliver the request to 
the backend services. The response from the backend 
service is then received by the application server and 
returned to the originating client. The framework 
enables customers to develop the business logic 
independent of the underlying transport layer and 
negate the need to modify the transport layer whenever 
a new domain model is introduced into the framework. 
The separation of the framework from the domain is 
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accomplished through the use of reflection by 
dynamically loading and executing the business logic at 
the application server once the client request 
specification is received. 

As described herein, the SI application 
server 2300 interfaces with the Legacy Backend 40(a), 
CSM/SI through a Requestor object 2310 and Receiver 
object 2350 as shown in Figure 25(b). Particularly, 
the SvcInqCSMRequestor object 2310 is the class that 
represents the requestor which takes the request data 
that comes from the Front -End/Client application 
through the Transaction Manager 2320, builds the CSM/SI 
request transactions by interacting with the Translator 
classes 2380 and ships off the requests to CSM. The 
request data that comes from the Front End/Client is an 
array of strings that are required from the customer 
for the request to be made. Minimal information is 
passed from the client to reduce the communication 
overhead from the client to the SI application server. 
All other information is packaged in the Requestor. 
Particularly, the Requestor object 2310 uses the 
SvcInqRegistryHeader and SvcInqSIHeader classes in the 
Translator 2380 to build the "Registry Header" and "SI 
Header" strings that are required for the CSM/SI 
request transactions. It also talks to the 
SvcInqActivity or the SvcInqRemarks classes to build 
the data portion of the CSM/SI requests. Once the 
CSM/SI Transaction String is formatted the actual 
request to CSM is made. Sending the transaction to 
CSM's Standard Interface (SI) via Registry classes does 
this. 

The receiver object is an instance of the 
SIRegistryHandler class whose responsibility is to 
obtain the responses from CSM, parse the response, 
strip off the headers and build objects from the 
response data, by interacting with the Translator 
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classes 2380. Particularly, it uses the SvcInqRemark, 
the SvcInqActivity, the SvcIngTroubleTicket or the 
SvcInqRegistryEntry class in the Translator to build 
the remark, activity, detail or list of Ticket object 
5 from the response string that is received from CSM. 

The built object is then sent back to the Transaction 
Manager 23 80 who passes it back to the Front - 
End/Client. 

Figure 7 (a) illustrates a diagram depicting 

10 the execution of a transaction by the SI application 

server 36 with each bubble representing a separate 
thread. The following itemized scenario describes the 
sequence of events in detail with each number in the 
scenario associated with the numbers in Figure 7 (a) . 

15 First, at step 501, the SI Application Server 

instantiates and starts the Transaction Manager 260 in 
a separate thread. The SI Application Server then 
instantiates and starts the Transaction Server 250 in a 
separate thread at step 502. The SI Application Server 

20 36 instantiates and starts the Registry Server in a 

separate thread at step 503. 

In operation, the Transaction Server receives 
a client transaction request, as shown at step 504. 
The connection is accepted and Transaction Handler 

25 thread is removed from the thread pool for execution, 

as indicated at 505. The Transaction Handler 
unpackages the transaction request at step 506 and puts 
the request message into the Transaction Manager f s 
RequestQ. The Transaction Manager 260 removes the 

30 request message from its RequestQ at step 507 and 

spawns a Transaction Executer thread to execute the 
transaction. Then, at step 508, the Transaction 
Executer translates the message and executes the 
transaction by loading the domain class and invoking 

35 the specified method which send the request to the 

backend services. 
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As indicated at step 509/ the backend service 
responds by sending the result of the transaction to 
the Registry Server which accepts the connection. At 
step 510, a Registry Handler is removed from the thread 
pool for execution for performing translation of the 
received message and placing the result into the 
Transaction Manager's ResponseQ, as indicated at step 
511. The Transaction Handler retrieves the transaction 
result from the ResponseQ at step 512 and the 
transaction response is delivered to the client at step 
513. 

The mainframe legacy backend 40(a) "Registry" 
is the cross -platform communication mechanism that is 
used by Service Inquiry to send messages to and receive 
messages from the CSM host. It shields applications 
from network protocols. CSM is provided with a 
mainframe database (not shown) that provides a set of 
Transactions to request CSM information through its 
Standard Interface (SI) which uses Registry as the 
messaging system. The Service Inquiry Application 
Server 2300 is configured to communicate asynchronously 
with CSM using Registry's RQS as the Inter- Process 
Communication (IPC) mechanism. Since CSM supports only 
one-way messaging, the communication between Service 
Inquiry and CSM/SI is asynchronous. When CSM 40(a) 
receives a request from the Requestor, it does not send 
any acknowledgment back to the requestor. The 
requestor only receives a confirmation from Registry 
that the request was successfully sent. When CSM 
finishes processing the request, it sends the response 
to the Receiver. 

Registry configuration consists of 
configuring the Registry client which sends request 
messages to CSM from the Service Inquiry Requestor and 
Registry server that receives responses from CSM and 
passes it to the Service Inquiry Receiver. As shown in 
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Figure 25(b) the Registry Queuing system, RQS is an 
asynchronous mode of inter process communication where 
there is one queue on the client and one on the server 
and there is only one TCP/IP connection always open 
5 between the client and the server. The client puts its 

requests on its own local queue 2322 and it is then 
forwarded to the queue on the server. The server takes 
the request off the queue, processes the request and 
the response messages are put in the client's queue 
10 2325. Since there is only one TCP/IP connection at any 

given time between the client and the server this mode 
is very efficient in terms of both network and system 
resources. 

As in the other application of the nMCI 

15 Interact suite, the Service Inquiry client application 

is written as a Java application to be executed at the 
client web browser running, for example, Microsoft 
Internet Explorer 4.0. The Service Inquiry client will 
be started from the networkMCI Interact homepage upon 

20 selection of the service inquiry icon 91 shown in the 

home page 70(a) of Figure 5(a). 

Figure 25(c) illustrates an example service 
inquiry main screen 2400 presented upon entry into the 
SI system selection. As shown in Figure 25(c), the 

25 Service Inquiry display 2400 presents a title bar, menu 

bar, tool bar, work area, and message window to provide 
the user alternative ways to manage different 
components of Service Inquiry product. It should be 
understood that any action available from the tool bar 

30 will also be available within the menu bar. 

Preferably, there are two permission levels that a user 
can have: 1) a View permission allowing a user to view 
the Service inquiry application desktop (Default 
Query) , define Service Inquiry queries, view the 

35 Details, remarks and activities, print, and report; 

and, 2) an edit permission allowing a user to create 
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trouble tickets, refer out trouble tickets, close 
trouble tickets, add remarks to trouble tickets, and, 
update trouble tickets. 

With more particularity, the menu bar 2410 
consists of the following items that correspond to the 
associated functionality: a File option 2410a including 
selections for creating a new ticket or new query, 
opening an existing query, saving a query being edited; 
printing and exiting the SI service; an Edit option 
2410b including selections for querying on a specific 
ticket number, closing a currently selected ticket, or 
referring back to a currently selected ticket; a View 
option 2410c including selections for showing details 
of a currently selected ticket, and refreshing current 
query results; a Tools option 2410d including 
selections for sorting tickets in the active window; 
and, a Help option. The tool bar 24 50 provides a 
Create button 2451 for creating a new ticket, a Query 
button 2452 for generating a new query, and, a find 
button 2453 enabling queries on a specific ticket 
number . 

The Query component of the Service Inquiry 
application enables Service Inquiry users to query 
trouble ticket information within the system, i.e., the 
listing or viewing of tickets based on, e.g., different 
selection criteria. This component also allows 
provides users with the ability to add remarks to 
tickets. A Default Query functionality is provided 
that allows users to keep a dedicated query available 
at all times. This query enables users to monitor the 
subset of tickets that are of most interest to them. A 
refresh mechanism is additionally provided so that the 
user may keep up with as current a status of these 
tickets as needed. The Default Query may be executed 
and displayed immediately on startup of the Service 
inquiry application and is available throughout the 
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Service Inquiry session. Preferably, the Service 
Inquiry application includes a set of predefined 
queries, one of which is preset as the Default Query 
and which may be redefined at any time. The user can 
only set their Default Query from a saved query. 

To create a new query, e.g., upon selection 
of the "Query", button 2452 from the tool bar 2450, a 
"Criteria" window is displayed such as the example 
window display 2460 shown in Figure 25(d) which enables 
the customer to select from among the following 
criteria to be used in the query: priority, status, 
identifier, open date, and ticket number. As criteria 
are selected from the "CRITERIA" tab 2462, new tabs 
(not shown) appear that are associated with the 
selected criteria. It is from these tabs that the 
actual parameters are specified for which the query is 
execute against. As the query is built, the parameters 
that are selected will populate themselves in the table 
2464 to the right of the tabbed panel. At any point in 
this selection process, the user may perform the 
following: move back and forth to any criteria tab by 
selecting the "Back" and "Next" buttons 2461a, 2461b 
respectively, or selecting the desired tab directly; 
add or remove criteria tabs by selecting or deselecting 
the associated checkbox from the "CRITERIA" tab 24 62; 
execute the query by selecting the "Execute" button 
2461c; save the query by selecting the "Save As" button 
2461d; remove highlighted parameters in the table by 
selecting the "Remove" button 2461e; or, remove all 
parameters in the table by selecting the "Remove All" 
button 2461f. 

As an example, a "List Tickets by Status 
Request" transaction will provide all the tickets for a 
given organization (ORG) code with the requested status 
and created after a specified date. The ORG code to be 
passed in this transaction is one of the selection 
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criteria representing the originating organization or 
the organization where the ticket was created. The 
customer may choose from a list of ORGs that the 
customer has authority over and a primary ORG is 
obtained from every customer and is stored locally in 
the user profile. The resulting information from all 
of the tickets will be cached for future processing. 
Generally, only one type of status may be specified in 
a single request: Open, Closed, Referred or Cancelled 
status. If a customer has authority over more than one 
organization that customer is able to view tickets for 
any organization he/she has authority over. If a 
customer has access to a primary organization, then 
he/she has implied access to all the subordinate 
organizations meaning that the request will apply to 
the subordinate organizations as well. Furthermore, 
this transaction may only display some of the 
details/fields of the tickets which means that the data 
cached from this request may only be used to process 
the Queries on tickets. It cannot be used to view all 
the details of the tickets for which further CSM/SI 
transactions will have to be made as will be herein 
described. 

Once the query is specified and executed, the 
"Query Results" window such as provided in the example 
window 2470 of Figure 25(e) is displayed to present the 
results of the query in a table 2472. Preferably, 
these results may be sorted by column by either 
clicking on the column in the table to sort by or by 
selecting "Tools/Sort" from the menu bar 2410. 
Selecting, ''Tools /Sort" from the menu bar will initiate 
display of a "Sort" window such as the example display 
2475 shown in Figure 25(f) which is capable of a three 
level sort by column in the table. The table columns 
can also be reordered by dragging and dropping them to 
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their desired locations- Details of a particular 
ticket may also be viewed. ~ 

The ability to save and retrieve queries 
allows a user to persist queries not only for the 
5 current session but for future sessions as well. This 

gives the user the ability to define a query once, then 
save it such that there will be no need to define it 
again, i.e., all the user needs do is retrieve and 
execute it. To save a query, the user must first create 

10 the query and then select the "Save As" button which 

enables display of the "Save As" window such as the 
example window 2480 shown in Figure 25(g) . This window 
enables a user to select from the list of existing 
saved queries or type a new name in entry field 2481. 

15 If an existing saved query is selected it's query will 

be copied over and its name will refer to this new 
query. A checkbox 2482 is available to designate this 
new query as the Default Query. To retrieve a saved 
query, e.g., upon selection of the "File/Open/Query" 

20 from the menu bar 2410, an "Open Query" window such as 

the example window 2485 shown in Figure 25(h) is 
displayed which provides a list of all saved queries. 
Once the desired query is selected the user may perform 
the following: execute the query i.e., run the query 

25 and display the results in the "Query Results" window 

or the "Default Query" window if the user selects it as 
their default query; or, edit the query by bringing up 
the "Criteria" window 2460 (Figure 25(d)) with the 
appropriate parameters already in the table. 

30 The customer may then view the results of a 

query, i.e., the details, remarks or activities of a 
Ticket chosen from a list of Tickets. To view the 
details of a ticket, the user may either select it from 
the query results and select "View/Details" from the 

35 menu bar or double click the ticket in the query 

results. Particularly, a "Display Ticket Request 
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Transaction" (CSM/SI transaction) may be used to obtain 
the details, activities and remarks of a ticket. This 
transaction allows several display requests to be made, 
e.g., by setting corresponding flags to f Y f . Whenever 
the customer wishes to view details, remarks or 
activities of a particular ticket, this request will be 
made with all the three flags set and the ticket number 
stuck into the SI header which will generate three or 
more responses. The "Display Detail Response 
Transaction" is a response that returns all the data 
elements corresponding to a given ticket in a "Details" 
window such as the example window 2490 shown in the 
Figure 25 (i). This window 2490 provides information 
about the selected ticket including: ticket number, 
ticket priority, ticket status, ticket identifier, 
ticket product, ticket service, date occurred, trouble 
description, and organization (ORG) . It should be 
understood that the number of data elements will be 
different for different types of tickets. 

Alternately, to find a ticket, e.g., upon 
selection of the "Find" button 2453 from the tool bar 
2450, the CSM/SI Transaction, "Display Ticket Request 
Transaction" is invoked, where the ticket number is 
passed on the request for handling as described above. 
It should be understood that, in the preferred 
embodiment, a "Change Ticket Request Transaction" may 
be implemented allowing the customer to change some of 
the fields of a ticket that is already created. This 
restriction is enforced by the GUI as this CSM/SI 
transaction does not impose any such conditions on the 
field being modified. 

Remarks are comments added to a ticket for 
historical purposes and can aid in the resolution of 
the problem. A customer must be viewing the particular 
ticket's details that contain the remarks desired. The 
"Display Remarks Response Transaction" is a response 



-120- 



WO 99/15979 



PCT/US98/20170 



that shows all the comments added on the ticket either 
by the customer or by the enterprise (MCI) . The CSM 
legacy system supports "public" and "private" remark 
types. Thus from the "Details" window 2490 shown in 
Figure 25 (i), the user may click on the "Remarks" 
button 2491 which will bring the "Remarks" window such 
as the example window 2495 shown in Figure 25 (j). From 
the remarks window, the remarks for that ticket are 
displayed. It should be understood that remarks may be 
added to a ticket for historical purposes, e.g., to aid 
in the resolution of the problem. From the "Remarks" 
window the customer may click on the "Add Remarks" 
button 2496 which enables display of the "Add Remarks" 
window (not shown) which allows the customer to add 
remarks to that Ticket. Thus, by implementing an "Add 
Remarks Request Transaction", the customer may add 
remarks on a ticket that is in an open 'status at any 
time. This may be used as a final step, just after 
creating a ticket, for example, to enable the customer 
to describe the trouble in his/her own words or add any 
comments. This transaction returns a success or 
failure response. 

Activities are events that occur to a ticket 
throughout its lifecycle. These events include 
changing status, changing priority, and reassignment of 
the person working the ticket. The customer must be 
viewing the particular ticket's details that contain 
the activities desired. The "Display Activity Response 
Transaction" is a response that provides all the 
activities, i.e., actions that have been taken on the 
ticket. Specifically, from the "Details" window 2490 
(Figure 25 (i) ) , the customer may click on the 
"Activities" button 2492 which will bring up the 
"Activities" window 249 8 such as shown in the example 
screen display (of Figure 25 (k) . From the activities 
window, the activities for that ticket are displayed. 
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This is a useful transaction in checking the status of 
a ticket and, it aids in tracking a ticket as it shows 
which organization the ticket is currently in. 

The create component of Service Inquiry 
application provides Service inquiry customers with the 
ability to create a ticket within the system. The 
first step in the creation of a trouble ticket is to 
identify the Event -Type/Call -Type of the problem which 
is basically the way CSM handles different problem 
types and is required for most CSM/SI transactions. To 
do that the client front end asks the customer the 
problem/ identifier type and then narrow down the 
problem by having the customer choose from a list of 
Product types, Service types and Trouble Descriptions 
as described herein with respect to Figure 25(1). 
(Based on these choices the system maps it to the 
correct Event -Type/Call -Type which mapping is done 
using database tables stored locally on the client. 
Once the Event -Type/Call -Type is determined, the data 
fields that correspond to that Event -Type/Call -Type is 
obtained from the database tables. The information 
required for all these fields is then gathered from the 
customer by presenting appropriate questions. Once all 
the required information is available, the system 
performs an "Open Ticket Request Transaction" and 
passes all of the data fields. The CSM legacy system 
then attempts to open a Trouble Ticket based on the 
data passed, and performs an "Open Ticket Response 
Transaction" to indicate if the ticket was created 
successfully along with the ticket number. Based on 
this response a confirmation message along with the 
ticket number is displayed to the customer. 

As an example, to create a service request 
from scratch, the customer may select, for example, the 
"Create" button 2451 from the tool bar 2450 of Figure 
25(c). This will initiate display of a "Create" window 
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such as the example window 2500 shown in Figure 25(1). 
From this window, the customer provides answers to the 
questions for each tab 2510 shown as questions 2512, 
and clicks the "Next" button 2514 when ready to go to 
the next set of questions. As the next tab appears, 
the answers from the previous tab populate the table 
2515. The user may navigate via the "Back" and "Next" 
buttons or by using the tabs. In the preferred 
embodiment, the questions are dynamic depending on 
previous answers. Thus, if the user goes back and 
changes the answer to a question that later questions 
depend on, then those questions will be overwritten by 
the new set of questions. The user will be warned if 
this is the case. 

Once the ticket is opened, it has to be 
referred out to a "Customer Facing -Organization" to 
initiate the problem resolution process. To do this, 
the CSM system refers the ticket out to an organization 
obtained from the user up front and stored in the User 
Profile- This is done using an "Enter Activity Request 
Transaction" which allows the customer to enter 
different activities like ' Refer Out 1 , "Close 1 , 'Refer 
Back 1 and 'Open 1 on a ticket by passing the appropriate 
activity code. 

Finally, the SI application allows the 
customer to close the ticket by using an "Enter 
Activity Request Transaction" described with respect to 
ticket creation. When a customer wishes to close a 
ticket, the system will make this transaction on behalf 
of the customer by passing the activity code for 
•Close 1 . A customer is allowed to close a ticket only 
if it were created by that organization and if the 
ticket is currently in that organization, i.e., it has 
been referred out to that organization. Since only the 
organization that opened the ticket has authority to 
close it, once a ticket has been resolved the ticket is 
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referred out to the customer's organization. If the 
customer is not satisfied with the problem resolution, 
that customer may refer the ticket back to the. 
enterprise (MCI) . This is also accomplished using the 
Enter Activity Request Transaction. Again, the system 
will make this transaction and pass the activity code 
for 1 Refer Back 1 . 

The creation of trouble tickets through 
Service Inquiry will now be described in greater detail 
in view of Figure 25 (m). In the preferred embodiment, 
the Service Inquiry application implements a domain 
object model (DOM) 2600 that allows the collection of 
information regarding a problem with a product offered 
by MCI. The questions that need to be asked to open a 
ticket vary by product and problem type. In addition 
to specifying a problem with a particular product, 
Service Inquiry provides the user with the 
functionality to perform queries for Trouble Tickets 
and to view the details of Trouble Tickets. The DOM's 
responsibility is the creations and query of Trouble 
tickets and it accomplishes it via interaction with the 
client presentation layer and interaction with the 
back-end systems. Information that is gathered via the 
presentation layer is used to construct backend 
transactions. The information returned from these 
backend transactions is formatted to DOM classes, which 
are forwarded to the presentation layer. 

As shown in Figure 25 (m) , the TroubleTicket 
2610 is the root of the Service Inquiry DOM. 
TroubleTicket instances contain identifying information 
that is used by the presentation layer to sort and 
filter a collection of TroubleTickets . The 
TroubleTicket class is responsible for accepting 
requests from the presentation layer, forwarding the 
requests to the backend and returning results to the 
presentation layer. In addition to maintaining 
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identifying information a Trouble Ticket also contains 
references to a QuestionTree 2620 and a Registry 2650, 

Specifically, a Question Tree 2600 is 
comprised of three Domain Classes: QuestionTree 2620, 
5 Question 2630 and RegistryEntry 2640. QuestionTrees 

2620 are essentially a set of questions for a 
particular product and problem type. The QuestionTree 
is responsible for the grouping of questions and the 
navigation between the groups. In addition, a 

10 QuestionTree knows if it has been completely specified, 

i.e., all of its required Questions have been answered. 
Within a QuestionTree, the group or category is 
designated by a unique name String) . Preferably, 
questions are store in a hashtable (not shown) . A 

15 group name is the key and a vector of Questions is the 

value for each entry in, the hashtable. The order of 
the groups is significant and since hashtables do not 
maintain order, a vector of Group names is required. 
This Vector of names is used for some of the 

20 navigational behaviors of a QuestionTree. 

The Registry 2650 is responsible for 
maintaining collections of objects that represent 
information retrieved from CSM via the client 
interface. The collections of objects represent 

25 Remarks, Details and Activities in CSM. Remarks and 

Details are also represented by vectors of instances of 
a "RegistryEntry" class. Activities are represented by 
a vector of instances of the Activity class 2660 which 
is an information holder having instance variables 

30 containing information that corresponds to fields in 

the CSM/SI Activity Record. 

The RegistryEntry class is a class in the 
Servicelnquiry DOM comprising instances 2640a that are 
used by Question instances 2630 and instances 2640b, c 

35 used by Registry instances 2650. When used by a 

Question, RegistryEntry instances 2640 represent the 
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possible choices for answers to the Question. Once the 
user selects a RegistryEntry "choice", this 
RegistryEntry instance becomes the answer to the 
question. When used by a Registry, the RegistryEntry 
instances 2640b, represent remark or detail information 
respectively, that is retrieved from CSM/SI. 
Specifically, RegistryEntry 2640a, b,c comprise the 
following instance variables: 1) a Text instance 
variable which is an optional variable used 
to specify text that will be presented to the user as a 
choice for an answer to a Question if the value is 
different than that specified by the registryvalue; 2) 
registryKey instance variable which maps to a key in 
CSM/SI; 3) a registry value instance variable which 
maps to the value in CSM/SI specified by the key in 
registryKey; 4) a nextGroupID instance variable which 
is an optional field used by the Question to assist the 
QuestionTree in some navigational tasks; and 5) a 
question instance variable which is a reference to the 
Question instance to which this RegistryEntry belongs. 
A RegistryEntry is contained by its Question; this 
instance variable is a back-pointer. 

The Registry Classes, i.e., classes that 
represent CSM/SI Registry records, have two additional 
responsibilities that are variations of a single 
behavior. The Registry Classes (RegistryEntry and 
Activity) are used for communication between Service 
inquiry and CSM/SI. CSM/SI requires Remark, Detail and 
Activity information in fixed- length field record 
format; Service Inquiry requires Remark, Detail and 
Activity information in an object format (instances of 
Registry Entry or Activity) . To provide these two 
formats, the Registry classes contain behavior to 
convert instances to fixed- length field record format 
and to instantiate themselves from fixed- length field 
record format. 
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Questions are the main component in a 
QuestionTree. A Question has a vector of group 
identifiers that indicate the groups to which it 
belongs. A Question has a vector of RegistryEntry 
instances 2640a called choices. When the user 
"answers" the Question, the answer is set to the 
selected choice; i.e., the selected RegistryEntry. 
Short answer or text answer Questions are a 
specialization of this behavior. Within each group of 
Questions, there is one question that is designated as 
the decision point which is used to determine the next 
group of Questions that need to be presented to the 
user. As a Registry Entry may contain a nextGroupID, 
the nextGroupID of the RegistryEntry instance selected 
as an answer to a decision point Question is used to 
derive the next roup of Questions. Occasionally, the 
only difference between the two groups of Questions is 
the inclusion or exclusion of a particular Question. 
One solution is to create two identical groups, one 
with the optional question and one without and rely on 
the decision point mechanism. In the preferred 
embodiment, an optional parent -child relationship 
between Questions is created. The inclusion/exclusion 
of a Question (child) in a group is based on the answer 
to a previous Question (parent) . A child Question 
maintains a reference to one of the possible choices 
(RegistryEntry) of the parent Question. If the parent 
Question's answer is the same as the child Question's 
parent Answer, the child Question is included in the 
group; otherwise, it is excluded from the group. 

TFNM 

As mentioned above, another application of 
the suite of telecommunications network management 
applications is the toll free network management tool 
800 as shown in Figure 26. Referred to herein as 
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"TFNM, the toll free network management tool 200 
provides the client GUI and middle- tier service that 
enable customers to request, specify, receive and view 
data pertaining to their toll free network management 
assets, e.g., toll free number routing plans, and to 
generate orders for changing aspects of the routing 
plans via a World Wide Web interface. Particularly, 
customer directives are entered by the user 100 via a 
TFNM graphic user interface. These directives are 
preferably communicated as Java applets over secure 
TCP/IP socket connections for input over the firewall 
25a to at least one secure Web server 24, e.g., a DMZ 
Web server that provides for authentication, 
validation, and session management in the manner as 
described herein. In view of Figure 26, as will be 
described, the TFNM tool 800 implements a TFNM domain 
server 840 which is one component part of a back-end 
MCI infrastructure comprising: MCI's NetCap system 
240, a Service Control Manager 290a ("SCM"), and Data 
Access Points 290b ("DAP"). Particularly, the legacy 
NetCap order entry system 290 processes (i.e., edits, 
validates, logs) call routing feature orders for 
customer's 800/8xx traffic and submits orders to the 
Service Control Manager ("SCM") which then formats and 
distributes orders to each of three redundant data 
access points ("DAPS") which implements the plan orders 
at the network switches. Once an order is implemented 
on the DAPS, calls to the customer ! s 800/8xx number are 
processed with the features specified in the order. 
The TFNM server 840 interfaces with the "NetCap" 290 
mainframe system that provides user interface to the 
network control system, i.e., DAP switches 290b. The 
TFNM domain server 840 includes Java object classes 
whose methods are invoked by Java applets running on 
the customer browser. The browser Java applets 
specifically execute the customer directives by 
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invoking certain methods on the TFNM Domain server 840. 
These Java objects additionally provide the interface 
functions to the NetCap 240. in the preferred 
embodiment, the Java objects at the TFNM domain server 
function as a proxy, and are invoked remotely 
implementing a Java remote method invocation "RMI" -like 
methodology. 

Particularly, as described herein with 
respect to Figure 3, within the networkMCI Interact 
framework for producing Java applications over the 
Internet, there is provided common objects and an 
infrastructure allowing secure communications between a 
client (which resides on a browser) and a server (which 
resides safely within MCI's firewalls). As briefly 
mentioned, the security strategy includes: encrypting 
communication from the client to the web- server via SSL 
(HTTPS) and implementing HTTPS as the preferred method 
for allowing communication into the web server from the 
Internet; providing an additional firewall between the 
web- server and the dispatcher to allow only specific 
traffic from the web server to the dispatcher to occur; 
encrypting traffic between the web server and the 
dispatcher via DSA encryption; and enabling the 
dispatcher to validate all packets destined to internal 
MCI servers to ensure that they are from an 
authenticated client, and that a particular client has 
permission to communicate with a specific back-end 
server. To make this seamless for the client, the 
aforementioned set of common objects performs this 
messaging. In the preferred embodiment, the invention 
implements a modified RMI which is referred to as 
"CORMI" (Common Objects RMI) which provides an RMI-like 
interface between the client and the server using the 
networkMCI Interact protocol. The CORMI procedures 
implemented have additional controls built in to 
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provide the necessary session security and maintenance 
for communication over the firewalls. 

More specifically, CORMI is nMCI Interact' s 
protocol for providing secure, client- to -server 
communication with Java RMI-like semantics and 
comprises a library of Java classes used by both the 
client applet and server application. In view of 
Figure 26, the communication path from the client and 
the server is as follows: 

The TFNM server application 840 registers 
remote objects with CORMI 's CORemoteSessionServer 
(analogous to Java RMI's Registry service) and then 
blocks waiting for connections. The TFNM client applet 
initiates communication by performing a logon through a 
COClientSession object. The COClientSession creates a 
COSynchTransaction (an atomic unit of work based over 
an HTTPS socket) which connects to the MCI Interact 
system dispatcher server 835 (which is behind the outer 
firewall 25(b)) and interfacing with StarOE server 39. 
The dispatcher server 26 validates the client's 
authorization to logon (a process that involves 
contacting the StarOE service and generating a session 
key with a 'cookiejar' process). After validating the 
client, the dispatcher uses a roundrobin protocol to 
select a TFNM server and then opens an HTTPS connection 
to an instance of the TFNM server application. On this 
server, the CORemoteSessionServer creates a new session 
for this client and records the session key. 

A reply to a logon is sent back through the 
dispatcher server 235 to the client 20. The client 
then can do a lookup which results, in a serialized 
remote interface of the remote object registered 
earlier being passed back to the client. The client 
can then use this remote interface as it would with 
Java RMI- doing remote method invocations. The remote 
method invocations are handled by CORMI as 
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COSynchTransactions through the Dispatcher to the same 
TFNM server instance that the logon and interface 
lookup took place at. 

It should be understood that there is no 
permanent connection between the TFNM client and 
server; CORMI, through a COSynchTransaction, creates a 
new HTTPS connection to the dispatcher (and the 
dispatcher creates a connection to the TFNM server) for 
each unit of communication. 

After the above -described logon, 
authentication and entitlement processes, the user is 
presented with the nMCI Interact home page (Figure 
5 (a) ) whereby the user may select the Network Manager 
icon 89 to enter into the TFNM system. Upon selection 
of the Network Manager icon, a client TFNM application 
is downloaded to the customer who is presented with the 
TFNM webpage display 1640, such as shown in Figures 
27(a) - 27(c). As shown, this TFNM web-page display 
presents a variety of TFNM file menu options including: 
1) an option 1645 enabling a user to select a Corp ID, 
i.e., a corp, set, number, and plan to establish a 
working environment; 2) an option 1646 enabling a user 
to cut -through to a 3270 mainframe NetCap application; 

3) an option 1647 enabling a user to Implement Plan, 
i.e., put a plan in use by creating an IMPL order; and, 

4) an option 1648 enabling a user to modify the 
termination information on a plan by creating a QUIK 
order. As further shown in Figure 27(b), the open menu 
includes a Plan option 1642 which allows the user to 
select from a list of plans in the current working 
environment and enables opening of the plan in a 
graphical mode on a VORT ("View Only Routing Tree"), as 
will be explained; and a Tree View option 1643 which 
displays the last plan accessed on the VORT screen. As 
further shown in Figure 27 (c) , the report menu includes 
an option 1644 for allowing the user to set up and 
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execute an order filter query which results in the 
display of an order list, as will be hereinafter 
described in greater detail. 

Thus, the customer is enabled to select a 
view of his/her routing plans in accordance with that 
user's privileges. To determine privileges, TFNM user 
security profile information is requested from StarOE 
that comprises a list of Corp Ids and Accessld 
combinations, referred to herein as 11 RACF ID" 
combinations that the customer is allowed to access 
within TFNM. Particularly, user security profile 
elements obtained from StarOE include: Corp Id, i.e., 
the Corporation Id the customer user has access to 
within StarOE; and Defaultlnd f i.e., a default Corpld 
indicator having, for example, ' Y ' or 1 N 1 values. 

Once the customer has logged into TFNM and 
has received the StarOE security message, a 
communication is made from the TFNM server 840 to 
NetCap 290 requesting a user security profile. 
Particularly, the messaging system implemented for all 
communications between the TFNM server and NetCap is 
referred to herein as "Registry", such as shown and 
described in commonly- owned, co- pending U.S. Patent 
Application No. 08/560,550, the contents and disclosure 
of which are incorporated by reference as if fully set 
forth herein. Security from NetCap is by Racf Id and 
Corp Id. For each Corp Id a user has access to, that 
user must have a Racf Id. If a user has Enterprise 
level security, then the list of Corps under that 
Enterprise within NetCap have the same security as the 
Enterprise. Particularly, in response to a user login, 
in the preferred embodiment, a TFNM server application 
is executed. From this application, the TFNM server 
instantiates a Profile Manager Java object which is 
registered with CORMI and called upon to invoke further 
objects relating to the following: user profile, e.g., 
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preferences, user security profiles, i.e., for tracking 
customer entitlements/privileges including rights for 
creating or modifying specific TFNM routing plans or 
generating QUIK or IMPL orders; and, session 
management, i.e., objects which encapsulate the state 
and behavior associated with a specific user login, 
e.g., time logged in. 

In the preferred embodiment, once profile 
manager is instantiated, the TFNM server additionally 
instantiates objects related to view screens and 
options according to the user's 

entitlements/privileges. Specifically, a Corporation 
Manager ( "CorpMngr" ) object is invoked to enable the 
user to select the corporation having the desired 
routing plan to be looked at. Then, the following 
objects are sequentially invoked: a Set Manager object 
for the corporation selected; a Number Manager object 
that knows the TFNM numbers (e.g., l-800/8xx) belonging 
to the Set and/or Corp; and, a Plan Manager object, 
which knows the routing plans that belong to the 
selected corporation, set, and/or number selected by 
the user up to that point. It should be understood 
that the TFNM server is enabled to communicate with 
NetCap server for this data if not provided in the TFNM 
database, or, if the information in TFNM is not 
current. For instance, for some messages, a data sync 
may always be invoked. Thus, TFNM may contact NetCap 
and pass date and time stamps indicating the last 
update for the record. If NetCap determines that they 
have later data version, it will pass down the updated 
version, otherwise, it will pass an empty message back 
to TFNM. Alternately, an internal table 845, as shown 
in Figure 26, may be accessed indicating the intervals 
for data record updates and which will indicate the 
last time a data sync was performed for a particular 
record. By checking this table, a determination may be 
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made as to whether contact must be made to NetCap for a 
data update. 

In the preferred embodiment, as shown in 
Figure 26, the TFNM server 840 communicates a plan/data 
sync message 843 via Registry messaging to NetCap. The 
Registry message call "NPSNC" is the request to sync a 
plan and transmit from the TFNM server to NetCap. A 
variety of Registry response messages for this request 
may be provided. 

As shown in Figure 27 (d) , the File/Select 
Corp ID menu option causes a screen 1650 to be 
displayed in the web page that enables the user to 
select elements (Corp ID, Set ID, Routing Number) that 
invoke objects for establishing a working environment, 
or, to select a plan for view. The data elements 
displayed on this screen differ according to the type 
of plan chosen. In the preferred embodiment, the TFNM 
Network Manager component 800 enables the customer to 
create or modify orders for four types of TFNM routing 
plans: a Number Level Plan ("NLP"), Super Routing Plans 
("SRP"), Enhanced Voice Service Routing plans ("EVS") , 
and universal routing plans ( ,f URP" ) . As shown in 
Figure 27(d), Number Level, EVS, or Super Routing plan 
radio buttons 1655 may be selected to access 
corresponding visible screen elements. When an NLP 
plan is selected, for instance, the following elements 
are displayed: a Corp ID element 1656 which is a single 
selection list box that becomes populated with corp 
id's available to the user in accordance with that 
user's entitlements; a Set ID element 1657 which is a 
single selection list box populated with Set ID'S that 
the user has security access to for a chosen Corp ID; a 
Number list box element 1658 which is a single 
selection list box populated with number information 
for the indicated corp. /set; and, a Plan list box 1659 
which is a single selection list box populated with 
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plan information such as: a plan description, plan in 
use, or when the plan was last modified, for a selected 
number. It should be understood that corporate 
security is obtained from NetCap whenever a new Corp ID 
is selected, in the manner described. 

In the preferred embodiment, using additional 
buttons 1652, 1653 and 1654 from the screen shown in 
Figure 27(d), the user respectively, is enabled to open 
or close the "Plan" portion of the screen; save the 
selected corp/set/number/plan id as the user's current 
working environment; and/or display a tree view of the 
highlighted plan. 

When the user chooses to view a selected 
routing plan, and after verifying security with both 
StarOE and NetCap, the TFNM server may execute the 
synch process with NetCap 290 as described above. 
During this process, TFNM updates any records in the 
TFNM server copy of the customer's chosen routing plan 
with changes that were made in NetCap since the user 
last accessed the stem. The TFNM server database is 
updated with the latest routing plan information for 
that customer, and the updated routing plan information 
is sent to the user, as indicated at step 333. The 
customer is now presented with the requested routing 
plan view via the TFNM client application. 

A user may view a routing plan in several 
formats, e.g., a hierarchical tree graphic or a 
spreadsheet. In the preferred embodiment, as shown in 
the exemplar screen display 1660 of Figure 27(e), the 
Routing Plan is displayed as a tree structure 
comprising of a series of linked node types in a 
specific hierarchy. As shown in Figure 27(e), the 
screen is divided into two main sections: a first 
section 1662 comprising the geographical representation 
of the routing tree having nodes tree branches that can 
be expanded and collapsed; and, a second section 1663 
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for displaying the details of the currently highlighted 
tree node. The nodes types that are available include: 
1) a Plan node 1666a which is shown highlighted in 
Figure 27(e) and details the features for the plan; 2) 
an Origination node ("GRIG") 1666b which details the 
geographical elements used in determining where to 
route the call. Multiple Origination nodes may exist 
under a plan node; 3) a Day of Week node ("DOW") 1666c 
which details how to route calls based on days of the 
week. Multiple Day of Week nodes may exist under an 
Origination and all seven days of the week must be 
accounted for under each origination; 4) a Time of Day 
node ("TOD") 1666d which details specific time ranges 
for routing calls. Multiple Time of Day nodes may 
exist under a Day of Week and all 24 hours of the day 
must be accounted for under each Day of Week; and, 5) a 
Percent Logical Termination node ("%LTERM") 1666e which 
details where the calls terminate and at what 
percentage of the time. As shown in Figure 27(e), 
multiple %LTERM nodes may exist under a Time of Day. 
The percentages in "sibling" nodes must add up to 100 
percent. A user can select details of any node by 
clicking or scrolling Trigger Points (not shown) may 
also be displayed as children of the node they ride on. 
For example, a Trigger Point that rides on an 
Origination node would be displayed under the 
Origination on the same level as a Day -of -Week node. 
At each node, decisions related to the call routing are 
executed. 

As further shown in Figure 27 (e) , for a plan 
node, the corresponding plan detail screen 1663 is 
populated with the existing plan description; the Orig 
id of the default Orig on the plan; and Origination 
Features having values derived based on the features in 
use on the plan. Likewise, for an origination node 
1666b, the corresponding plan detail screen displays: 
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the ID of the highlighted origination node and the 
corresponding description including listboxes 
displaying the geographic elements (countries, states, 
area codes and exchanges) associated with the 
highlighted Origination node. For the DOW node 1666c, 
the corresponding plan detail screen displays the Day 
Id of the DOW node and the list of days associated with 
the DOW node. For the TOD node 1666d, the 
corresponding plan detail screen displays the list of 
time ranges associated with the TOD node. For the 
Termination node 1666e, the corresponding plan detail 
screen displays: the ID of the termination associated 
with the highlighted node; a description of the 
termination associated with the highlighted node; an 
indication of whether a cross corp term is associated 
with the highlighted node, and, if the Cross Corp Term 
indicator is "Yes" a field displaying the cross corp Id 
associated with the termination in the Termination ID 
field; and an indication of the percentage of calls 
allocated to this termination node. Further details 
may be displayed including a Details tab (not shown) 
for displaying: the customer service id associated with 
the termination; the activation date of the 
termination; the activation date received associated 
with the termination; the service status associated 
with the termination; the Switch Trunk ID associated 
with the termination; and, an indication of whether the 
termination is EVS; whether the Termination has a real- 
time ANI Delivery and, the activation date for the Real 
Time ANI. Additionally, an ANI tab (not shown) may be 
displayed for presenting the user with information as 
to whether the termination has an Automatic Number 
Identifier ("ANI"), the country code associated with 
the termination and the Termination ANI. An "Overflow" 
tab of the termination details screen displays for the 
user: a network call redirect indicator indicating 
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whether the termination has an NCR; a direct 
termination overflow indicator indicating whether the 
termination has a DTO. Likewise, a "DNIS" tab (not 
shown) may be displayed for presenting the user with 
information as to whether DNI Enhanced DNIS is active 
on the termination; the date that DNIS is activated; an 
indication of whether the Dialed Digit Out Pulsing 
(DDO) is active on the termination; the prefix digits 
used for DNIS, and the number of digits to be reused 
for DNIS. Finally, an "International Outbound" tab 
(not shown) may be displayed for presenting the user 
with information as to whether international outbound 
is active on the termination; the Country code 
associated with the termination if international 
outbound is active; the Carrier code associated with 
the termination if international outbound is active; 
and the free phone number associated with the 
termination if international outbound is active. 

Via the TFNM Client Application, the user is 
now able to invoke TFNM functions such as the "IMPL" 
depicted in Figure 26 as the IMPL request 822 which 
enables the user to quickly change the number routing 
plan that a working number or set of working numbers is 
routing to; or "quik" depicted in Figure 26 as the QUIK 
request 824 which enables the user to quickly add, 
change and/or delete one or more termination locations, 
and/or change the percentage allocation of two or more 
of these locations, for a currently implemented routing 
plan. In accordance with the present invention, 
additional directives may include: a temporary ("TEMP") 
IMPL directive which is created in conjunction with an 
Impl by entering a roll -back date so that the routing 
plan will revert to its prior use status prior to 
creation of the Impl; and a TEMP QUIK directive which 
enables roll -back of the changes made by a QUIK order 
to what they were before the QUIK. 
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For the case when a user desires to implement 
the IMPL/TEMP IMPL plan, or the QUIK/TEMP QUIK, the 
user selects the Setup IMPL from the TFNM screen. 
Specifically, the TFNM Client application causes the 
instantiation of an "Order Manager" object which 
invokes methods capable of accessing all the 
information pertaining to orders for a given corp id, 
set, TFNM telephone number and plan. An order 
comprises two components: 1) an order administration 
record comprising data such as: order status, effective 
at a time and order number, etc.; and, 2) order 
administration detail record which includes the 
detailed information pertaining to that order, e.g., 
changes to percent allocation or effective dates/times 
etc. for a plan, etc. The Order Manager object 
includes an ImplOrder sub -class which knows about IMPL 
orders, e.g., IMPL functionality, and invokes objects 
to obtain order records, pertaining to plans. As 
mentioned, an IMPL order allows a user to change which 
routing plan they want to be "in use" for a specific 
number or a set of numbers. 

Figure 27(f) illustrates the IMPL dialog 
screen 1670 enabling the user to generate a TEMP 
IMPL/IMPL order for the desired Corp Id. Particularly, 
as shown in Figure 27(f), a number/set selection dialog 
box 1671 is displayed having radio buttons enabling 
selection of the desired 800/8xx Number, a set of 
numbers, a reserved number; or, an EVS Number for 
implementing an EVS plan. Selection of one of these 
will invoke a "data controller" object for retrieving 
information from a TFNM database causing a 
corresponding dialog to appear enabling user search for 
the desired 800/8xx Number, set, reserved number, or 
EVS Number for the desired Corp Id. After selecting 
the desired number or set, the user is prompted to 
select from dialog box 1672 the specific plan type that 
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is to be IMPL'd for the number or set. As shown, the 
dialog box 1672 comprises radio buttons enabling user 
selection of the desired plan IDs including, but not 
limited to, a Number Level Plan ("NLP") implemented for 
an 800/8xx Number or a set of numbers, a Super Routing 
Plan (SRP) implemented for an 800/8xx Number, a set of 
numbers, or a reserved number; and, an EVS plan 
implemented for an EVS Number. It should be understood 
that if the user has privileges for only one Corp ID, 
the system will select only the plans associated with 
that Corp ID for the user. If the user has privileges 
for more than one Corp ID, the user is presented with a 
list of all Corp IDs and will select one Corp ID. Any 
subsequent actions the user takes within the 
application are applicable to that selected 
corporation. 

After having selected the Corp, set, Routing 
Plan Number or Routing Plan ID, the user may set or 
modify the routing plan. In the preferred embodiment, 
the user can define the routing plan according to any 
of the above -described options: Origin, Country, 
State, NPA, NXX, Day of week, Time of day, and 
Termination. These options can be defined for each 
Corp ID, Set or number. In the preferred embodiment, 
the user is enabled to implement NLPs, SRPs, and EVSs 
and URPs for a selected toll free number or, implement 
NLPs and SRPs for a set of numbers that they want 
routed differently. Via IMPL request messaging, the 
user selects the desired routing plan for the 
number/set and the desired date and time when they want 
to start routing the number to the selected plan and 
forwards the request to the TFNM server via HTTPS 
messaging. 

As shown in Figure 26, the customer's Send 
IMPL request 822 is communicated over the HTTPS 
connection as a request to invoke methods in the Order 
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Manager class/sub- classes via CORMI. Once the plan has 
been submitted to the TFNM server via the send IMPL 
message 822 , the TFNM server receives the new routing 
plan and verifies the user's security with NetCap. 
Once the user's security has been verified, the TFNM 
server submits the IMPL request to NetCap 290 via 
Registry messaging. Particularly, the Order Manager 
classes/sub -classes execute methods for translating 
the IMPL order in a form suitable for submission to 
NetCap. 

Included in the Registry message calls that 
are transmitted from the TFNM server to NetCap for the 
IMPL/TEMP IMPL order and the corresponding NetCap 
responses is the message for submitting an IMPL order 
(NIMPL) to NetCap. 

It should be understood that, in the case of 
a user implementing a TEMP IMPL request, the user 
follows the same procedure as for the IMPL order, e.g., 
selecting the desired routing plan for the number/set 
and Corp Id. However, as shown in Figure 27(f), the 
user is presented with a dialog 1673 for submitting the 
desired date and time when the user wants to start 
routing the number to the selected plan, and, a dialog 
1674 for submitting the roll back date and time when 
they want the previous routing plan to be effective 
again. Thus, both an IMPL and TEMP IMPL message pair 
is sent to the TFNM server for processing as described 
herein . 

After a TEMP IMPL and/or IMPL request has 
been transmitted to NetCap 290, it is stored for future 
implementation. In view of Figure 26, NetCap sends an 
acknowledgment via Registry messaging back to the TFNM 
server . 

Included in the Registry message calls that 
are transmitted to the TFNM server from NetCap in 
response to the submitted IMPL order is the message 
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indicating successful processing of the IMPL request 
(NSUCS) and the message indicating completion of the 
order in NetCap (UCOMP) . The TFNM server passes this 
information on to the user via CORMI messaging over the 
HTTPS connection. If the user is still logged on, this 
acknowledgment appears as a pop-up message on their 
screen, as indicated via line 826 in Figure 26. If the 
user has logged off, TFNM retains the acknowledgment 
that the IMPL has been received and saved for the next 
user logon. Likewise, when an IMPL has been 
transmitted to NetCap and either implemented or 
terminated, NetCap sends a registry message back to the 
TFNM server which, in turn, passes this information 
back to the user via HTTPS connectivity. 

The user of the TFNM system may instead 
desire to execute the QUIK feature that enables 
customers to quickly add, change and/or delete one or 
more termination locations (nodes) , and/or change the 
percentage allocation of two or more of these 
locations, for a currently implemented routing plan, 
Figure 27(g) illustrates an exemplary web-page screen 
1680 instantiated by the TFNM client application for 
the QUIL/TEMP QUIK order process which is presented to 
the user. As shown in Figure 27(g), there is provided 
a number of radio buttons which the user may select: 1) 
an 800/8xx number button 1682 which causes a dialog to 
be displayed for enabling the user to enter or select 
an 800/8xx number from a list of 800/8xx #'s (not 
shown) having an associated "plan in use" . Once the 
800/8xx # is entered, the system returns the 
corresponding NLP or SRP Plan in use; 2) an SRP button 
1684 which causes a dialog to be displayed for 
enabling the user to enter or select an SRP Id from a 
list (not shown) . Once entered, the system returns the 
SRP Routing Plan for the SRP Id; 3) an EVS button 1686 
which causes a dialog to be displayed for enabling the 
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user to enter or select an EVS number. Once entered, 
the system returns an EVS Plan In Use if available . In 
each dialog, a corresponding "data controller" object 
is invoked for retrieving information from a TFNM 
database causing a corresponding dialog to appear 
enabling user selection. 

After selecting the desired plan, the user is 
required to key or select each of the following 
buttons: Origination Id/Description 1687, Day of Week 
Id/Desc. 168, and Time Begin/Desc. 1689. Selection 
of the Origination Id/Description button 1687 causes a 
list of Origination Id and corresponding descriptions 
to be displayed. In this manner a user may scroll 
through the list and identify the branch comprising 
the terminations that are to be modified. Likewise, 
selection of the Day of Week Id/Desc. button 1688 
causes a list of Day of Week node ids/descriptions to 
be displayed for the selected Origination Id node and 
through which the user may scroll through and select 
for modification. Similarly, selection of the Time 
Begin button 1689 causes a list of Time of Day node 
ids/descriptions to be displayed for the selected DOW 
and through which the user may scroll through and 
select for modification. Through use of the Order 
Manager classes/sub-classes the system auto -populates 
the Orig, DOW, TOD, and, once populated, the system 
displays in display field 1692 the Lterms for the TOD 
node which comprise the terminations and percent 
allocations. In the preferred embodiment, the user may 
change percentage allocations by overtyping the amount 
or using the spin box up/down arrows 1690 (increments 
of 1 percent) . The user may additionally modify the 
percentages for the remaining termination (s) as long as 
the sum of the percentages for all the terminations 
attached to the selected Time interval node equals 100 
percent. Action keys 1695a- 1695d may additionally be 
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enabled for user selection in accordance with 
enterprise business rules and/or user security. 
Specifically, key 1695a enables the submission of the 
QUIK/TEMP QUIK order to NetCap for approval (Issue 
key) . Key 1695b allows the user to add a termination 
to the TOD node (including cross -corp terms that the 
customer has cross corp agreements with) , or change the 
termination id, description, or percent allocated to 
the termination for this plan. Preferably, selection 
of key 1695b enables display of a web page having a 
Termination screen enabling these choices. Key 1695c 
enables the user to select the termination that the 
user wants replaced and presents the user with the 
Termination screen to select the term for change 
(Change Term key) . The key 1695d enables the user to 
select the term they want to delete on the selected 
routing branch. In the preferred embodiment, the 
system defaults effective date/time to the current 
date/ time, however, the user may enter a future 
rollback date/time up to 1 year in the data and time 
entry fields 1696a, b in Figure 27(g). If the user 
enters a Rollback date/time in the rollback date 
fields, the system generates a TEMP QUIK order that 
sets the Routing Plan back to its state before the QUIK 
order. Preferably, the Rollback date/ time may not be 
greater than 1 year in the future. 

Thus, from the dialog box 1680 (Figure 
27(g)), the user is enabled to perform the following: 
1) change one or more terminations for NLP or SRP; 2) 
replace one or more terminations on an EVS Routing 
Plan; 3) change the percent allocation of currently 
implemented NLP, EVS, or SRP Plan; 4) add one or more 
terminations to the currently implemented NLP or SRP 
Plan; 5) add one or more terminations to an EVS Routing 
Plan; and, 6) delete one or more terminations from the 
currently implemented plan of an NLP, EVS or SRP Plans. 
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It should be understood that, in the case of a user 
implementing a TEMP QUIK request, the user selects the 
desired routing plan for the number/set, the desired 
date and time when they want to add, change and/or 
delete one or more termination locations and/or 
percentage allocation of these locations for a 
currently implemented routing plan, and, optionally, 
the roll back date and time when the changes are to 
revert back to their original settings. Thus, a QUIK 
and TEMP QUIK message pair is sent to the TFNM server 
for processing as described herein. 

Referring back to Figure 26, the customer's 
Send QUIK request 824 is communicated by the TFNM 
client applet by communication between the Dispatcher 
server 235 and the TFNM server objects using CORMI . 
The Object manager/sub- classes execute methods for 
translating the QUIK/TEMP QUIK order in a form suitable 
for submission to NetCap. 

Included in the Registry message calls that 
are transmitted from the TFNM server to NetCap for the 
QUIK/TEMP QUIK order and the corresponding NetCap 
responses is the message for submitting an QUIK order 
(NQUIK) to NetCap. 

Once the plan has been submitted to the TFNM 
server via the send QUIK message, the TFNM server 
receives the new routing plan and verifies the user's 
security with NetCap. Once the user's security has 
been verified, the TFNM server submits the QUIK request 
to NetCap 290 via Registry messaging. 

After a TEMP QUIK and/or QUIK request has 
been transmitted to NetCap, it is stored for future 
implementation. In view of Figure 26, NetCap sends a 
registry message to the TFNM server acknowledging that 
the request has been stored. 

Included in the Registry message calls that 
are transmitted to the TFNM server from NetCap in 
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response to the submitted QUIK order is the message 
indicating successful processing of the QUIK request 
(NSUCS) and the message indicating completion of the 
order in NetCap (UCOMP) . The TFNM server then passes 
this information on to the user via CORMI messaging 
over the HTTPS connection. If the user is still logged 
on, this acknowledgment appears as a pop -up message on 
their screen, as indicated via line 826 in Figure 26. 
If the user has logged off, TFNM retains the 
acknowledgment that the QUIK order has been received 
and saved for the next user logon. Likewise, when a 
QUIK has been transmitted to NetCap and either 
implemented or terminated, NetCap sends a registry 
message back to the TFNM server which, in turn, passes 
this information back to the user via HTTPS 
connectivity. 

As described, a change to a routing plan is 
saved locally before being submitted to NetCap. The 
submission happens when the plan changes are converted 
into an approved order having an approved order admin 
record and with a condition that NetCap has no 
preceding orders queued against the plan. The 
submission process takes place in two steps: first, the 
order admin record is sent to NetCap immediately, and 
second, when no orders are pending against the plan, 
the order admin detail record is then sent. The delay 
results because NetCap does not queue more than one 
order against a plan at a time. The TFNM server is 
configured to hide this limitation by stacking orders - 
a process of accepting multiple submissions and queuing 
them internally for later transmission to NetCap. The 
order admin record is sent immediately. The order 
admin detail record is sent soon as possible 
thereafter. 

Further functionality provided by the TFNM 
server is the ability to open plans, i.e., display a 
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list of routing plans under the current working 
environment for display as a VORT (Figure 27(e)), or, 
view orders and filter through orders. Particularly, 
the TFNM client will instantiate the Order Manager 
object which instantiates order administration detail 
objects and other objects for retrieving administrative 
records comprising the details for a particular order 
in the TFNM database. For example, selection of the 
Report Order menu option shown in the screen display of 
Figure 27(c), will cause the display of an order filter 
screen enabling a user to enter elements that they 
would like to use to query for orders and submit order 
queries. The results of an order query are displaced 
in an order select list 1698, such as shown in Figure 
27(h). From this list, a user can retrieve details 
pertaining to an order, or, change an order's status or 
update remarks. Particularly, from an administration 
button 1699, the user is presented with a dialog 1700 
as shown in Figure 27 (i), for example, enabling the 
user to update the order status and the effective 
date/ time. It is from these dialogs that a user may 
select a button 1703 to un- approve an order (if the ^ 
selected order has been approved by NetCap) and, a 
button 1704 to "zap" (delete) an existing order. 

The Registry message calls that are 
transmitted from the TFNM server to NetCap also include 
those for un- approving an order (NOUAP) zapping an 
order (NOZAP) , and, requesting pending order data 
(NPIUO) . Corresponding NetCap responses are provided. 

It should be understood that, in accordance 
with the principles described herein, the TFNM 
management tool of the invention is capable of 
supporting "feature" orders, i.e., functionality 
enabling customers to add a new TFN routing plan, e.g., 
NLP, SRP, URP, or EVS or, change other the attributes 
or structure of an existing plan, e.g., changing 
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attributes of a routing plan directly from the VORT 
(Figure 24(b)). The TFNM tool additionally may provide 
"drag and drop" enabling users to configure routing 
elements between plans. 

Although the TFNM web/Internet network 
management tool has been described herein with respect 
to a customer's toll-free, e.g., l-800/8xx networks, 
the principles may be readily applied to other types of 
telecommunications network numbers. 

ONM 

Another application of the suite of 
telecommunications network applications is the 
networkMCI Interact Outbound Network Manager 
application 2700. Referred to herein as "ONM", the 
outbound network management tool 2700 provides the 
client GUI and middle- tier service that enable 
customers to manage and track Calling Party Number 
Orders, Calling Card Orders, Dialing Plan Orders, and 
ID Code Set Orders relating to their private networks 
such as Vnet and Vision networks. 

As shown in Figure 28, the ONM tool 2700 of 
the invention implements an ONM domain server 2750 
integrated with a back-end MCI intranet and legacy 
system infrastructure comprising above -described MCI's 
NetCap order entry system 29 0, Service Control Manager 
290a ("SCM") and Data Access Points 290b ("DAP"). The 
ONM server 2750 enables customers to change their 
Vnet/Vision network management plans, both in real-time 
and on a scheduled basis, via NMCI Interact' s web-based 
front -end and middle- tier infrastructure. 
Particularly, customer order directives are entered by 
the customer 20 via an ONM graphic user interface. 
These directives are preferably communicated as Java 
applets over secure HTTPS socket connections 2722, 2724 
for input over the firewall 25 (a) to at least one 
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secure server, e.g., a DMZ Web server 24 that provides 
for authentication, validation, and session management 
in the manner as herein described. After validation 
and authentication, the DMZ Web server 24, in turn, re- 
encrypts messages and dispatches them to the Dispatcher 
26 server over TCP/IP connection 2734. The Dispatcher 
server may implement an ONM proxy 2735 which properly 
receives ONM order messages from the web server, and 
translates them into a format suitable for transmission 
over another TCP/IP connection 273 6 to the ONM domain 
server 2750. As will be described, the ONM domain 
server 2750 interfaces with the "NetCap" 290 mainframe 
system that provides user interface to the network 
control system, i.e., DAP switches 290b (Figure 6). 
The ONM domain server 2750 may include Java object 
classes whose methods are invoked by Java applets 
running on the customer browser. The browser Java 
applets specifically execute the customer directives by 
invoking certain methods on the ONM Domain server 2750. 
These Java objects additionally provide the interface 
functions to the NetCap 29 0. In the preferred 
embodiment, the Java objects at the ONM domain server 
function as the ONM proxy, and are invoked remotely 
implementing a Java remote method invocation "RMI l! -like 
methodology. 

Particularly, as described herein with 
respect to Figure 2, within the networkMCI Interact 
framework for producing Java applications over the 
Internet, there is provided common objects and an 
infrastructure allowing secure communications between a 
client (which resides on a browser) and a server (which 
resides safely within MCI's firewalls) . As described, 
the security strategy includes: encrypting 
communication from the client to the web- server via SSL 
(HTTPS) and implementing HTTPS as the preferred method 
for allowing communication into the web server from the 
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Internet; providing an additional firewall between the 
web -server and the dispatcher to allow only specific 
traffic from the web server to the dispatcher to occur; 
encrypting traffic between the web server and the 
dispatcher via DSA encryption; and enabling the 
dispatcher to validate all packets destined to internal 
MCI servers to ensure that they are from an 
authenticated client, and that a particular client has 
permission to communicate with a specific back-end 
server. To make this seamless for the client, the set 
of Common Objects performs this messaging. In the 
preferred embodiment, a "CORMI" (Common Objects RMI) 
which provides an RMI - like interface between the client 
and the server using the networkMCI Interact protocol 
is implemented. The CORMI procedures implemented have 
additional controls built in to provide the necessary 
session security and maintenance for communication over 
the firewalls. 

After customer logon, authentication and 
entitlement determination, a networkMCI Interact applet 
is downloaded to the customers Web Browser via the 
established TCP/IP connection, and the browser presents 
the customer with the networkMCI Interact systems home 
page including a Network Manager icon 89 (Fig. 5(a)). 
Selection of this icon, enables a client ONM 
application to be downloaded to the customer who is 
then presented with the ONM screen, as indicated at 
step 318. 

An exemplary ONM web-page display 2764 is 
shown in Figure 29(a) which presents a variety of ONM 
menu options including: 1) a File menu option 2702 
providing a selection 2704 for creating a new order, a 
selection 2706 for opening an existing order, a 
selection 2708 for displaying events, and a selection 
2710 for enabling 3270 cut through to a Vnet/Vision 
configuration management system; 2) an Edit menu 2715 
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providing options for deleting an ONM order or, 
enabling a search for specific components, e.g., within 
an Order detail and Inventory windows pertaining to a 
Calling Party Number ("CPN"), Calling Card, Dialing 
Plan, and ID Code/Set, such as will be described; 3) a 
Control menu 2720 providing a refresh option to enable 
a user to retrieve a list of all updated lists that 
have been altered on the host system including: Network 
IDs, Range Privileges, ID Code Set, Billing location 
ID, Customer Service ID, Location/Access type and 
Provisioning Carrier; arid 4) a Report menu 2723 
providing options enabling a customer to inquire on 
his/her inventory of CPNS, Calling Cards, Dialing Plans 
and ID Code Sets. 

With more particularity regarding the File 
menu option 2702, when a user selects the new order 
menu option 2704, he/she is presented with a drop down 
menu (not shown) presenting a section of the order 
types which can be created via their Web Browser, e.g., 
CPN, Calling Card, Dialing Plan, and ID Code Set. When 
the user selects the open order selection 2706 from the 
drop down menu of Figure 29(a), the user is presented 
with a web page 2725 displaying a request order window 
where the user may enter search criteria from which a 
user may select orders, or, choose all orders. As 
shown in Figure 29 (b) , the user may enter the following 
search criteria: an exact order number or partial order 
number in the "order match" field 2730; an order type, 
e.g., Calling Card, CPN, Dialing Plan, ID Code Set, or 
all, from a drop down list presented by "order type" 
drop down menu 2732; a starting date or current default 
date in the "starting date" field 2737; a user ID or 
default current user ID from the "user ID" field 2739; 
and, a set of order status check boxes 2740 which 
enables the user to choose an order status, e.g., not 
approved, approved, complete, and error/rejected. 
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When multiple orders are retrieved, as a 
result of an entered search criteria, a web page 2744 
presenting an "Orders" window will appear such as shown 
in Figure 29(c). From the Order detail window, an 
order may be selected, e.g., by double clicking an 
order summary line 2743. The field descriptions for an 
order displayed in the orders window include: an order 
Number 2745 which is a unique number assigned to the 
order for identification; a currently logged- on user ID 
2746; the current order status 2747; the order type 
2748, e.g., ID Code, as depicted in Figure 29(c); the 
date the order was prepared 2751, and the effective 
date/time 2752 when the order will be implemented in 
the network by the host. The details of an order may 
be retrieved by highlighting the order summary line 
2743 and pressing the details button 275453 or, by 
double- clicking the order summary line 2743. It should 
be understood that the user may retrieve a web page 
having an Order window by either selection of a New 
Order, from Figure 29(a), or, selection from the Open 
Orders Window, when retrieving existing order (s) . 

Selection of a new or existing CPN Order 
option via the nMCI Interact ONM system allows a 
customer to "link" or attach network features to any 
Calling Party Number (CPN) that exists in that 
customer's inventory, i.e., CPNs that are active in 
that customer's database. Preferably, the following 
features can be defined/linked to CPNs: 1) Multiple 
Networks; 2) Supplemental Codes including ID Codes and 
Accounting Codes; 3) Range Privileges including 
Universal and Customized; 4) Data vs. Voice 
Specification; and Extended Enterprise (Location/Access 
Type) . 

Figure 29 (d) illustrates a web page 2755 
comprising a CPN order window comprising the following 
sections: an order administration section 2760 for 
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handling administrative aspects of the CPN order; a CPN 
inventory section 2770 used to retrieve CPNs from 
inventory that are not included on another order. This 
is accomplished by selection of the retrieve button 
2775 and enables display of, inter alia, the CPNs and 
associated PINs, a description assigned to the CPN, and 
a component count; a CPN updates section 4800 which 
populates the CPN order window by moving selected 
calling cards from the cards in inventory section or by 
adding new calling cards to the current order; and, an 
attributes section 2790 for populating an area of the 
web page screen display 2755 with a list of attributes, 
or features, for a selected CPN in the inventory or 
updates section. 

With more particularity, the CPN order 
administration section 2760 of web page display 2755 
comprises the following field descriptions: 1) a field 
2762 enabling a customer to set the date/time when the 
order is to be implemented by the host. For example, a 
default time is the current PC date and time, shown in 
the format of MM/DD/YYYY HH:MM (24 hour clock); 2) a 
field 2764 enabling the establishment of a priority 
(depending on security access privileges) ; 3) a field 
2766 for describing the order's current status. For 
example, new CPN orders default to "not approved"; 4) a 
Remarks text field 2767 optionally used to describe the 
contents of the CPN order; and, 5) an Approve field 
2768 such that when checked, indicates the order is 
approved and transmitted to the host. After 
transmission, the field name changes to Approved and 
the Order Status field displays Approved. It should be 
understood that, if authorized, a customer may 
unapprove an approved order that has not completed by 
reselecting the Approved check box. A pop-up message 
(not shown) in the web display will prompt the customer 
to confirm the action. 
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With more particularity, the CPN inventory 
section 2770 used to retrieve CPNs from CPN order 
inventory comprises the following field/command button 
descriptions: a CTRY field 2772 including a three-digit 
country code for the CPN; a CPN Beginning field 2774 
comprising the remaining digits of the CPN or the 
beginning number within a range; a Description field 
2776 comprising an alphanumeric description assigned to 
the CPN, e.g., the CPN location or company name; a 
Component Count field 2778 indicating how many CPNs are 
within the CPNs in Inventory section; a Retrieve button 
2775 such that, when selected, retrieves a list of a 
customer's available CPNs in inventory that are not 
included in other orders. Selection of this option 
will enable a web page display of a Retrieve CPNs from 
Inventory Window 2812 such as shown in Figure 29(f); 
and, a right arrow ">" command button 2779 enabling a 
customer to move single or multiple (selected) CPNs 
from the CPNs in inventory section to the CPN Updates 
to include in the current order. 

With more particularity, the CPN updates 
section 2780 comprises the following field/command 
button descriptions: a status code indication field 
2781 displayed next to a CPN, with the following 
designations: a (blank) indication meaning no status; 
an "A" indicating that a new CPN is being added, e.g., 
Stentor customers; a "C 11 displayed next to CPNs that 
have been changed; and a "D" indicating that a CPN has 
been marked for deletion; a CTRY field 2782; a CPN 
Beginning field 2783; a Description field 2784; and, a 
Component Count field 2787 as described above; a left 
arrow "<" command button 2788 enabling a customer to 
remove a CPN from the current order, and to restore its 
attributes back to those that were last transmitted to 
the host, i.e., move one or more highlighted CPNs to 
the CPNs in Inventory section; an "Add" command button 
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2785, e.g., displayed for Stentor customers, which 
presents a web page having an Add New CPN window such 
as shown in Figure 29(c); and, a "Delete" command 
button 2786, e.g., displayed for Stentor customers 
5 marks the highlighted CPN displayed in the CPN Updates 

section for deletion. 

With more particularity, the CPN attributes 
section 2790 comprises the following field/command 
button descriptions: an "Item" field 2792 comprising 

10 those Vnet/Vision feature items that are listed in this 

column once linked to CPN(s) , e.g., Range Privilege, ID 
Code Set, etc.; a "Value" field 2793 which comprises 
the defined value of the network features (e.g., U 001) 
linked to CPN(s) ; a "CPN Nbr" field 2794 which 

15 designates the information displayed in the Attributes 

section is for the selected CPN, which can be either in 
the CPNs In Inventory or CPN Updates sections; a 
"Variable" field 2795 which changes according to the 
item selected in the Attributes section and enables 

20 customers to add/change information for the selected 

item, except when any prepopulated information is 
dimmed; a <Set Dflt> button 2796 which enables a 
customer to define the PC default for CPN attributes. 
Once set, the PC default values can be applied to other 

25 CPNs by selecting the <Use Dflt> button 2797 which 

command provides the option of applying either the host 
default or the user-defined PC default attributes for 
the selected CPN. For example, if the Location Type of 
the current CPN is "C", default attributes that would 

30 change it to "A" or "B" cannot be applied. On the 

other hand, if Location Type "C" was established as a 
default with <Set Dflt>, a pop-up message will prompt 
the user to confirm using it as a default when you 
select <Use Dflt>; an <Undo> button 279 8 for removing 

35 any changes made to the selected CPN, and restoring its 

attributes back to those that were last transmitted to 
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the host, an <Expand> button 2799 enabling the display 
of the Calling Party Number Attributes window, such as 
shown in Figure 29(g); and a <Close> button 2791 for 
closing the CPN Order window. 
5 The Add New CPN window 2800 such as shown in 

Figure 29(e) enables a customer, if authorized, to add 
a new CPN to their inventory and assign it attributes. 
In the example web page display shown in Figure 29 (e) , 
the Add new CPN functionality includes: assigning a 

10 provisioning carrier in entry field 2802; adding a CPN- 

From number in entry field 2804; adding a CPN-To number 
in entry field 2806; and, adding a CPN description in 
entry field 2808. Preferably, the added CPN(s) are 
displayed in the CPN Updates section 2780 with the "A" 

15 indication 2781 as shown in Figure 29(d). It should be 

understood that CPN orders may be deleted by selecting 
the delete button 2786 (Figure 29(d)). 

As mentioned above, selection of the CPN 
Retrieve button 2775 enables a web page display of a 

20 Retrieve CPNs from Inventory Window 2812 such as shown 

in the example web page display of Figure 29(f) . From 
this window, a customer may specify search criteria or 
retrieve a predetermined amount of CPNs having 
defaulted criteria. Particularly, the Retrieve CPNs 

25 from Inventory Window 2812 comprises the following 

field/command button descriptions for retrieving CPNs 
from customer inventory: a country field 2814 for a 
country code from a drop-down list by selecting a 
"down" arrow 2 815 when specifying a CPN in the CPN From 

30 field; a CPN From field 2816 enabling a customer to 

enter a partial or whole CPN, e.g., from 3-25 numeric 
characters. The nMCI Interact ONM system matches the 
partial CPN and retrieves the first 10 exchanges 
available in inventory; a Quantity field 2817 enabling 

35 a customer to enter a value, from 1 to 200 per CPN 

group, specifying the quantity of CPNs to include in 
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the retrieval; a Network ID field 2818 enabling a 
customer to select a specific Network ID from the drop- 
down list by selecting the down arrow; a Range 
Privilege field 2819 enabling a customer to select a 
specific Range Privilege from the drop- down list by- 
selecting the down arrow; an ID Code Set field 2820 
enabling a customer to select a specific ID Code Set 
number from the drop -down list by selecting the down 
arrow. It should be understood that ID Code Sets must 
be defined prior to creating the CPN Order, as will be 
described herein; a Description field 2821 enabling a 
customer to type a full or partial CPN description as 
retrieval criteria; an <Add> button 2 823 for updating 
the list box with the group information from the 
Country, CPN From, Quantity, Network ID, Range 
Privilege, ID Code Set and Description edit boxes; a 
<Remove> button 2825 enabling a customer to remove a 
highlighted display item so that it is not included in 
the retrieval request; an <0K> button 2826 for 
accepting all entries in the Retrieve CPNs from 
Inventory window, and messaging the host. If nMCI 
Interact ONM finds one or more CPNS that matches 
specified search criteria, it will close the Retrieve 
CPNs from Inventory window. If the Retrieve CPNs from 
Inventory window is accessed from the CPN Order window, 
the results are displayed in the CPNs in Inventory 
section and replaces any CPNs that may have been in 
this section prior to retrieval; and, a <Cancel> button 
2827 for closing the Retrieve CPNs from Inventory 
window without accepting any changes. 

As mentioned above, selection of the CPN 
attributes <Expand> button 2799 (Fig. 29(d)) enables a 
web page display of a Calling Party Number Attributes 
window 2830, such as shown in the example web page 
display of Figure 29 (g) . From this window, a customer 
may "view only" CPN attributes or features, if the 
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selected CPN is located in the CPNs in Inventory 
section of the CPN order window, or, view or modify 
attributes if the selected CPN is in the CPN Updates 
section. 

As shown in the example web page display of 
Figure 29(g), a first section referred to as the CPN 
information section 2840 comprises view only fields 
presenting information such as: a three digit country 
code field 2841 which identifies the country of origin 
for this CPN; a "From" field 542 indicating the 
beginning number of a possible range of CPNs affected 
by this CPN Order; a "To" field 2843 indicating the 
last number of a range of numbers affected by this CPN 
Order; a Customer Account field 2844; a Division ID 
field 2845; a Description field 2846 describing the 
CPN(s); and, a yes or no Cellular field 2847 indicating 
whether this CPN originates from a cellular phone. 
Additionally, a second section referred to as the CPN 
feature information section 2850 comprises the 
following field/command buttons including: a Network ID 
field 552 obtained from the drop- down list by selecting 
the down arrow; a Range Privilege field 2853 for 
selecting the Range Privilege (customized or universal) 
to be linked to this Calling Card from the drop-down 
list by selecting the down arrow; an ID Code Set field 
2854 for selecting an ID Code Set to be associated with 
this CPN from the drop-down list by selecting the down 
arrow. When an ID Code Set is chosen, nMCI Interact 
ONM automatically populates the ID Code Length; a Supp 
Code Collection field 2855 enabling selection from the 
drop down list to indicate when ID and/or accounting 
codes will be collected for this CPN. A tone will 
prompt callers to enter code(s) after the dialed 
number. Selections include: 0 - Do not collect 
Supplemental Codes; 1 - Collect Supplemental Codes for 
all numbers; 2 - Collect Supplemental Codes on all 
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calls except 7 -digit Private On -Net Numbers; 3 - 
Collect Supplemental Codes only for international Off- 
Net numbers; 4 - Collect Supplemental Codes for all 
Off -Net numbers; a Data Indicator field 2856 enabling a 
5 user to denote data versus voice traffic by selecting 

from the drop-down list; a Prov Carrier 2857 indicating 
the provisioning carrier (MCI or Stentor) associated 
with the CPN, in the format of Country Code, padded to 
three digits with leading zeros, and the 4 -digit 

10 Carrier Code; a Location Type field 2858 which may be 

selected by clicking on the down arrow to activate the 
drop down list; an ID Code Length field 2859 which is 
autopopulated with a 2 -digit number according to the ID 
Code Set selected; an Account Code Length field 2860; 

15 and, <Set Default>, <Use Default>, <OK> and <Cancel> 

option buttons, as described herein. 

When opening an existing Calling card order, 
the nMCI Interact ONM system Calling Card Order option 
allows a customer to "link" or attach network features 

20 to a Calling Card(s) that exist in that customer's 

inventory, i.e., Calling Cards that are active in that 
customer's database, or link network features to a new 
calling card. The following features can be 
defined/linked to Calling Cards: 1) Multiple Networks; 

25 2) Range Privileges including Universal and Customized; 

Range Restrictions including Corporate and Custom; and 
Extended Enterprise (Location/Access Type) . 

Figure 29 (h) illustrates an example web page 
2870 comprising a Calling Card order window comprising 

30 the following sections: 1) an order administration 

section 2880 for providing administrative aspects of 
the Calling Card order such as: enabling entry of a 
date/ time when the order is to be implemented by the 
host; selecting a priority based on the user's security 

35 access privilege; establishing an order status, e.g., 

approved or not approved for new orders in accordance 



-159- 



WO 99/15979 



PCT/US98/20170 



with a users authorization; 2) a Cards in inventory 
Section 2890 used to retrieve Calling Cards from 
inventory that are not included on another order. This 
is accomplished by selection of the retrieve button 
2895 and enables display of, inter alia, the Calling 
card numbers and associated PINs, a description 
assigned to the calling card, and a component count; 3) 
a Card updates section 2900 which populates the calling 
card order window by moving selected calling cards from 
the cards in inventory section or by adding new calling 
cards to the current order; and, 4) an attributes 
section 2910 for populating an area 2912 of the screen 
display with a list of attributes, or features, for a 
selected calling card in the inventory or updates 
section. 

With more particularity, the Calling Card 
order administration section 2880 of web page display 
2870 comprises the same field descriptions as mentioned 
herein with respect to the CPN order administration 
including: 1) a set date/ time field 2882 for when the 
calling card order is to be implemented by the host; 2) 
a priority field 2884 for establishing calling card 
order priority (depending on security access 
privileges); 3) a current order status field 2886; 4) a 
Remarks text field 2889 optionally used to describe the 
contents of the Calling card order; and, 5) an Approve 
field 2888 such that when checked, indicates the order 
is approved and transmitted to the host. 

The Calling Card inventory section 2890 used 
to retrieve a Calling Card(s) from the Calling Card 
inventory comprises the following field/command button 
descriptions: a Card Nbr-PIN field 2892 that displays 
the Calling Card number and associated PIN if the user 
has security access to view the PINS; a Description 
field 2894 which comprises a description assigned to 
the Calling Card, e.g., the employee or company name; a 
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Component Count field 2896 indicating how many Calling 
Cards are within the Calling Cards Inventory section; a 
Retrieve button 2895 such that, when selected, 
retrieves a list of a customer's available Calling 
cards in inventory that are not included in other 
orders. Selection of this option enables a web page 
display of a Retrieve Calling Cards from Inventory 
Window 2920 such as shown in Figure 29 (i); and, a right 
arrow ">" command button 289 8 enabling a customer to 
move single or multiple (selected) Calling Cards from 
the Calling Cards in inventory section to the Calling 
card Updates to include on the current order. 

The Calling card updates section 2900 
comprises the same field/command button descriptions as 
mentioned herein with respect to the CPN order 
administration including: a status code indication 2901 
displayed next to a Calling card having the same 
designations, i.e., no status, "A", "C", and "D"; a 
Card Nbr-PIN field 2902, a Description field 2903 and, 
a Component Count field 2904 as described above; a left 
arrow "<" command button 2905 enabling a customer to 
remove a Calling card from the current order, and to 
restore its attributes back to those that were last 
transmitted to the host, i.e., move one or more 
highlighted Calling cards to the Calling cards in 
Inventory section; an "Add" command button, e.g., only 
displayed for Stentor customers; and, a "Delete", 
command button. 

The Calling Card attributes section 2910 
comprises the same field/command button descriptions as 
mentioned herein with respect to the CPN order 
administration including: a table 2912 including an 
item field 2911 comprising those Vnet/Vision feature 
items that are listed in this column once linked to 
Calling cards, e.g., Range Privilege, Location type, 
etc.; a "Value" field 2913; a "Card Nbr" field 2914 
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which designates the information displayed in the 
Attributes section is for the selected Calling card, 
which can be either in the Calling card In Inventory or 
Calling cards Updates sections; a <Set Dflt> button 
2915 which enables a customer to define the PC default 
for Calling card attributes. Once set, the PC default 
values can be applied to other Calling cards by 
selecting the <Use Dflt> button 2916 which command 
provides the option of applying either the host default 
or the user -defined PC default attributes for the 
selected Calling card; ain <Undo> button 2917; an 
<Expand> button 2918 enabling the display of the 
Calling Card Attributes window, such as shown in Figure 
29 (j); and a <Close> button 2919 for closing the 
Calling card Order window. 

As mentioned above, selection of the Calling 
card "Retrieve" button 2895 in Figure 29(h) enables a 
web page display of a Retrieve Calling cards from 
Inventory Window 2920 such as shown in the example web 
page of Figure 29 (i). From this web page, a customer 
may specify search criteria or retrieve a predetermined 
amount of Calling cards having defaulted criteria. 
Particularly, the Retrieve Calling cards from Inventory 
Window 2920 comprises the following field/command 
button descriptions for retrieving Calling cards from 
customer inventory: a Card Nbr field 2921 enabling 
entry of a partial or whole 10 -digit calling card 
number; a PIN field 2922 enabling entry of an optional 
4 -digit personal identification number that is 
associated with the Calling Card number and can only be 
used in combination with Card Nbr; a Quantity field 
2923 enabling a customer to enter a value, from 1 to 
200 per Calling card group, specifying the quantity of 
Calling cards to include in the retrieval; a Network ID 
field 2924; a Range Privilege field 2925 enabling a 
customer to select a specific Range Privilege from the 
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drop -down list by selecting the down arrow; a 
Description field 2926 enabling a customer to type a 
full or partial Calling card description as retrieval 
criteria; an <Add> button 2927 for updating the list 
box with the group information from the Card Nbr, PIN, 
Quantity Network ID, Range Privilege, and Description 
edit boxes; a <Remove> button 2928 enabling a customer 
to remove a highlighted display item so that it is not 
included in the retrieval request; an <OK> button 2929 
for accepting all entries in the Retrieve Calling cards 
from Inventory window, and messaging the host; and, a 
<Cancel> button 2930 for closing the Retrieve Calling 
cards from Inventory window without accepting any 
changes . 

As mentioned above, selection of the Calling 
card <Expand> button 2918 (Fig. 29(h)) from the calling 
card attributes section enables a web page display of a 
Calling card Attributes window 294 0, such as shown in 
Figure 29 (j). From this window, a customer may "view 
only" calling card attributes or features, if the 
selected calling card is located in the Cards in 
Inventory section of the calling card order window, or, 
view or modify attributes if the selected calling card 
is in the Card Updates section. As shown in the web 
page display of Figure 29 (j), a first section referred 
to as the calling card information section 2935 
comprises view only fields presenting information such 
as: the Calling Card Number 2936 and the associated PIN 
2937; the Customer Account number 293 8; and the calling 
card description 2939 which is user- defined and 
accessible. Additionally, a second section referred to 
as the feature information section 2941 comprises the 
following field/command buttons including: a Network ID 
field 2942 obtained from the drop-down list by 
selecting the down arrow; a Range Privilege field 2943 
for selecting the Range Privilege (customized or 
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universal) to be linked to the Calling Card from the 
drop-down list by selecting the down arrow; a Range - 
Restriction field 2944 for selecting a Corporate or 
Custom Range Restriction to be linked to this Called 
Card from the drop- down list by selecting the down 
arrow; a Prov Carrier field 2946 which indicates the 
provisioning carrier (MCI or Stentor) associated with 
the Calling Card, in the format of Country Code, padded 
to three digits with leading zeros, and the 4 -digit 
Carrier Code; a Location Type field 2948 for example, 
host default, which, once selected, cannot be changed 
until the Calling Card is deactivated and reinstalled; 
a <Set Default> button; an <Use Default> button; an 
<0K> command button for returning to the Calling Card 
Order window; and a <Cancel> button for exiting the 
Calling Card Attributes window without making changes 
to the feature information. 

In a similar manner as described above with 
respect to the Add New CPN web page display (Figure 29 
(e) ) , a Stentor customer, if authorized, may add a new 
Calling Card to their inventory and assign attributes. 
The Add new Calling Card functionality includes: 
assigning a card number and associated personal 
identification number (PIN) , adding a provisioning 
carrier in the format of a country code, and, adding a 
Calling card description. It should be understood that 
Calling card orders may be deleted by selecting a 
delete button. 

When opening an existing Dialing Plan order 
or creating a new one, the nMCI Interact ONM system 
Dialing Plan Order option allows a company to define 
their call routing Dialing Plans to meet their business 
needs and manage their network costs. Thus, the nMCI 
Interact Outbound NM Dialing Plan order enables a 
customer to: 1) Create 7 -digit Private Numbers that 
translate to Public Numbers, used for caller 
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convenience and easy association of locations; 2) Force 
Public Numbers On-Net so that it is no longer routed 
according to Public Network rules, but rather by the 
customer's dialing plan; 3) Exclude a specific number, 
or range of Public Numbers, to control network abuse; 
assign specific numbers to terminate to Customized 
Message Announcements to provide user -defined 
information lines; and, establish "Hotlines" to enhance 
customer service by providing caller convenience and 
local presence. 

Within a dialing plan order, a user may 
specify the origination, or dialed digit range (the 
number dialed) , and the termination data (where or how 
the call is answered, e.g., terminating to Dedicated 
Access Lines (DALs) . 

Figure 29 (k) illustrates an example web page 
comprising a Dialing Plan order window 2950 comprising 
the following sections: 1) an order administration 
section 2960 for providing administrative aspects of 
the Dialing Plan order such as: enabling entry of a 
date/ time when the order is to be implemented by the 
host; selecting a priority based on the user's security 
access privilege; establishing an order status, e.g., 
approved or not approved for new orders in accordance 
with a users authorization; 2) a Dialing Plans in 
inventory section 2970 used to retrieve Dialing Plans 
from inventory that are not included on another order. 
This is accomplished by selection of the retrieve 
button 297 5 and enables display of the country codes 
associated with the Dialing Plan; display of the dial 
plan single number or beginning number within a range; 
a termination type for the dialing plan; and, a 
component count indicating the amount of dialing plans 
that are in the inventory section; 3) a Dialing Plan 
updates section 2980 for populating the dialing plan 
order window by moving selected dialing plans from the 
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Dialing Plan inventory section or by adding new dialing 
plans to the current order; and, 4) an attributes 
section 2990 for populating an area of screen display 
2950 with a list of attributes, or features, for a 
5 selected dialing plan in the inventory or updates 

section. 

With more particularity, the Dialing Plan 
order administration section 2960 of example web page 
display 29 50 comprises the same field descriptions as 

10 mentioned herein with respect to the CPN order 

administration including: 1) a set date/time field 2961 
for when the dealing plan order is to be implemented by 
the host; 2) a priority field 2962 for establishing 
dialing plan order priority {depending on security 

15 access privileges); 3) a current order status field 

2963; 4) a Remarks text field 2964 optionally used to 
describe the contents of the Dialing Plan order; and, 
5) an Approve field 2965 such that when checked, 
indicates the order is approved and transmitted to the 

20 host. 

The Dialing Plans in Inventory section 2970 
used to retrieve Dialing Plan(s) from the Dialing Plan 
inventory comprises the following field/command button 
descriptions: a Ctry field 2971 that displays the 

25 Dialing Plan's country code; a Dial Plan Beginning 

field 2972 indicating the remaining digits of the 
Dialing Plan number of beginning number within a range; 
a type field 2973 indicating the termination type for 
the dialing plan; a Component Count field 2974 

30 indicating how many Dialing Plans are within the 

Calling Cards Inventory section; a Retrieve button 2975 
such that, when selected, retrieves a list of a 
customer's available Dialing Plans in inventory that 
are not included in other orders. Selection of this 

35 option will enable a web page display having a Retrieve 

Dialing Plans from Inventory Window 3000 such as shown 
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in Figure 29(1); and, a right arrow ">" command button 
676 enabling a customer to move single or multiple 
(selected) Dialing Plans from the Dialing Plans in 
inventory section to the Dialing Plan Updates to 
5 include on the current order. 

The Dialing Plan updates section 2980 
comprises the same field/command button descriptions as 
mentioned herein with respect to the CPN updates 
section including: a status code indication 2981 

10 displayed next to a Dialing Plan having the same 

designations, i.e., no status, "A" (added), "I" 
(changed), and "D" (deleted); a Ctry field 2982, a Dial 
Plan Beginning field 2983, a termination "type" field 
2984, and, a Component Count field 29 85 as described 

15 above; a left arrow "<" command button 29 86 enabling a 

customer to remove a Dialing Plan from the current 
order, and to restore its attributes back to those that 
were last transmitted to the host, i.e., move one or 
more highlighted Dialing Plans to the Dialing Plans in 

20 Inventory section; an "Add" command button enabling 

entry of new Dialing Plan record (s) ; and, a "Delete" 
command button for deleting Dialing Plan records. 

The Dialing Plan attributes section 2990 
comprises the same field/command button descriptions as 

25 mentioned herein with respect to the CPN attributes 

section including: an "Item" field 2992, e.g., Network 
ID; a "Value" field 2994; a "Dial Nbr" field 2996 
which designates the information displayed in the 
Attributes section is for the selected Dialing Plan, 

30 which can be either in the Dialing Plans In Inventory 

or Dialing Plan Updates sections; an <Undo> button 
2997; an <Expand> button 299 8 enabling the display of 
the Dialing Plan Attributes window, such as shown in 
Figure 29 (m) ; and a <Close> button 2999 for closing the 

35 Dialing Plan Order window. 
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As mentioned above, selection of the Dialing 
Plan "Retrieve" button 2975 in Figure 29 (k) enables a 
web page display of a Retrieve Dialing Plans from 
Inventory Window 3 000 such as shown in the example web 
5 page of Figure 29(1). From this display, a customer 

may specify search criteria or retrieve a predetermined 
amount of Dialing Plans having defaulted criteria. 
Particularly, the Retrieve Dialing Plans from Inventory 
Window 3 000 comprises the following field/command 

10 button descriptions for retrieving Dialing Plans from 

customer inventory: an International Direct Dialed 
Digits "IDDD" radio button 3001 enabling entry of 
dialed digits as a public number in a dialed digits 
field 3003. When IDDD is selected, the user is 

15 required to designate a Country Code in a Country field 

3002; a Private radio button 3005 enabling entry of a 
Private Number in the Dialed Digits field when 
selected. The Country field is protected when this 
type of dialed digits is selected; a Country field 3002 

20 that must be selected from the drop -down list when IDDD 

is selected as the type of dialed digits; a dialed 
digits field 3003 enabling entry of a partial or whole 
number (dialed digits) not including the Country Code) ; 
a Quantity field 3004 enabling a customer to enter a 

25 value, from 1 to 100, specifying the quantity of 

Dialing Plans to include in the retrieval; a Network ID 
field 3006; a Termination/Location ID field 3008 
indicating the Location ID of a DAL which can be 
selected from the drop-down list (if available within 

30 the customer's network); an <Add> button for updating 

the list box in the selected dialing plans section with 
the group information from the IDDD, Private, Country 
(only when IDDD is selected), Dialed Digits, Quantity, 
Network ID and Termination Location ID edit boxes, 

35 where applicable; a <Remove> button enabling a customer 

to remove a highlighted display item so that it is not 
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included in the retrieval request; an <OK> button for 
accepting all entries in the Retrieve Dialing Plans 
from Inventory window, and messaging the host; and, a 
<Cancel> button for closing the Retrieve Dialing Plans 
from Inventory window without accepting any changes. 

As mentioned above, selection of the Dialing 
Plan <Expand> button 2998 from the Dialing Plan 
attributes section enables a web page display of a 
Dialing Plan Attributes window 3020, such as the 
example web page display shown in Figure 29 (m) . From 
this display, a customer may view Dialing plan 
attributes or features, if the selected dialing plan is 
located in the Dialing Plans in Inventory section of 
the Dialing Plans Order window, or, view or modify 
attributes if the selected calling card is in the 
Dialing Plan Updates section. 

As shown in the web page display of Figure 
29 (m) , a first section referred to as the Dialed Digit 
Range section 3022 comprises fields /command buttons 
enabling a customer to define the origination data 
(number dialed) for a dialing plan. The field/command 
buttons include: "type" radio buttons 3 025 enabling the 
selection of the originating number as a private number 
or public number (IDDD) ; a country field 3026 for 
enabling entry of a country code from a drop -down list 
when IDDD is selected as the dialed digit type; a 
network ID field 3027 enabling entry of a network in 
which a new Dialing plan is defined; a "From" field 
3028 enabling entry of a beginning number of a range of 
numbers; a "To" field 3029 enabling entry of a last 
number of a range of numbers; a Carrier ID field 3 023 
which is an optional entry for numbers defined in the 
Dialing Plan order that are only completed by the DAP 
if originated by the specified Carrier Code within that 
originating country, and, that are only entered when a 
Country and Carrier Code is specified. 
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As shown in the example web page display of 
Figure 29 (m) , a second section referred to as the 
Termination section 3030 comprises fields /command 
buttons enabling a customer to define the termination 
data for a dialing plan. The field/command buttons 
include: location name field 3031 which is an 
alphanumeric field enabling entry of a description of 
the termination, e.g., company name or location; a type 
field 3032 enabling selection from a drop- down list of 
the following termination types to which the Private or 
Public Number sends the call: a DAL - used for 
Dedicated Access Lines, an IDDD - used for all Public 
Numbers, a CMA - used for Customized Message 
Announcements, and, a EXCL used to exclude a number or 
range of numbers; a Location ID field 3 033 of a 
Dedicated Access Line (DAL) which can be entered (e.g., 
Shared DALs) or selected from the drop-down list. If 
the termination type is "DAL", a section/entry is 
required; a County field 3034 for selection of the 
Country Code (where call will terminate) from the 
values in the drop- down list and is required entry when 
"IDDD" is the termination type; a Prefix Digits field 
3 035 for entering the numbers at the beginning of the 
terminating number (not including the Country Code) 
which are the same for all numbers in a range, or the 
entire terminating number when entering individual 
numbers; a Reuse Digit Length field 3036 enabling entry 
of the number of digits from the dialed digits that 
will be reused in the terminating number when used in a 
range with Prefix Digits. This field displays the 
default value, e.g., "00", and is protected when 
terminating numbers are entered individually or when 
the termination type is CMA or EXCL. When a value is 
required, it can either be typed in or selected from 
the drop -down list; a Nature of Subsequent Address 
field 3037 enabling entry of the out pulse digits 
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delivered to a customer's equipment (CPE). When the 
termination type is a DAL, the default is changed from 
"None" to any of the other selections. However, 
''Subscriber" is typically selected, as "National" and 
"International" would only be used by a private network 
owner; a Point of origin Routing Indicator check box 
303 8 to indicate Point of Origin Routing which enables 
a customer to designate an alternate DAL, that 
overrides the DAL specified in that customer's Dialing 
Plan, based on the originating switch. This helps to 
manage load balancing for DALS, e.g. for Vnet; and, an 
<OK> button and a <Cancel> button for closing the 
Dialing Plan Attributes window without making changes 
to the feature information. 

When opening an existing ID Code/ Set order or 
creating a new one, the NMCI Interact ONM system ID 
Code/Set Order option allows a customer to define a 
unique 1 - 11 digit number ID Code and assign that 
number to an individual. ID Codes preferably have a 
range privilege assigned to them, therefore, a customer 
can tailor calling privileges and assign them to 
individuals via their ID Code. Once an ID Code system 
is established, the code is entered after the dialed 
number on every call made. It should be noted that the 
network DAP switches (Figure 28) verifies ID Codes. 
Thus, a correct ID Code must be entered or the MCI 
switch will not complete the call. In the preferred 
embodiment, there are two types of ID Code Set Orders 
in nMCI Interact Outbound NM: 1) Add/Change ID Code Set 
Order; and 2) Delete ID Code Set Order. 

In the preferred embodiment, the Add/Change 
ID Code Set Order enables a customer to perform the 
following functions to implement ID Codes within that 
customer's Vnet/Vision Network: 1) Define ID Code 
Length (1 - 11 digits); 2) Assign Range Privileges to 
ID Codes; 3) Define Local Sets; 4) Generate ID Codes 
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Sequentially or Randomly to an ID Code Set; 5) 
Individual Entry of ID Codes; and 6) Modify/Delete ID 
Codes within a Set. 

Figure 29 (n) illustrates an example web page 
3050 comprising an Add/Change ID Code Set Order Window 
comprising the following sections: 1) an order 
administration section 3051 for providing 
administrative aspects of the order such as: enabling 
entry of a date/ time when the order is to be 
implemented by the host; selecting a priority based on 
the user's security access privilege; establishing an 
order status, e.g., approved or not approved for new 
orders in accordance with a users authorization; 2) an 
ID Code Sets in Inventory section 3060 used to retrieve 
ID Code Sets from inventory that are not included on 
another order. This is accomplished by selection of 
the retrieve button 3065 and enables display of the ID 
Code Set details including: ID Code, Set ID, set types, 
defined ID Code length; a description of the ID Code 
Set, e.g., by location; and, a component count 
indicating the amount of ID Code Sets in the ID 
Code/Sets inventory section; 3) an ID Code Set Updates 
Section 3070 for populating the ID Code/Set order 
window by moving selected ID Code/Sets from the ID 
Code/Set inventory section or by adding new ID Code/Set 
to the current order; and, 4) an attributes section 
3080 for populating an area of screen display with a 
list of attributes, or features, for a selected ID 
Code/Set in the inventory or updates section. 

With more particularity, the ID Code Set 
Order administration section 3 051 of web page display 
3050 comprises the same field descriptions as mentioned 
herein with respect to the Dialing Plan order 
administration including: 1) a set date/time field 3052 
for when the ID Code/Set order is to be implemented by 
the host; 2) a priority field 3053 for establishing 
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dialing plan order priority (depending on security 
access privileges); 3) a current order status field 
3054; 4) a Remarks text field 3055 optionally used to 
describe the contents of the ID Code/Set order; and, 5) 
an Approve field 3056 such that when checked, indicates 
the order is approved and transmitted to the host. 

The ID Code/Sets in inventory section 3060 
used to retrieve ID Code/Set (s) from the ID Code/Sets 
inventory comprises the following field/command button 
descriptions: a Set field 3061 indicating the ID 
Code/Set; a "type" field 762 having an indication of a 
local ("L") set or a global ("G") set; a Len field 3063 
indicating the defined length of the ID Code; a 
description field 3064 indicating the description of 
the ID Code Set, e.g., location; a Component Count 
field 3066 indicating how many ID Code Sets are within 
the ID Code Sets in Inventory section; a Retrieve 
button 3065 such that, when selected, retrieves a list 
of a customer's available ID Code Sets in inventory 
that are not included in other orders. Selection of 
this option will enable a web page display having a 
Retrieve ID Code Sets from Inventory Window 309 0 such 
as shown in Figure 29 (o) ; and, a right arrow ">" 
command button 3067 enabling a customer to move single 
or multiple (selected) ID Code Sets from the ID Code 
Sets in inventory section to the ID Code Set Updates to 
include on the current order. 

The ID Code Sets updates section 3070 
comprises the above -described Set, "type, 11 Len, 
description and component count fields and, a left 
arrow command button 3068 enabling a customer to 
move one or more highlighted ID Code Sets to the ID 
Code Sets in Inventory section; a "Delete" command 
button; and, an "Add" command button 3069 enabling the 
addition of new ID Code Sets to the order including 
functionality enabling the creation of an ID Code Set 
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which can be added to an order and which must contain 
at least one ID Code prior to approving the order. 
Adding a new Set to the order entails specification of 
either a local or global ID Codes sets. 

The ID Code Sets attributes section 3080 
comprises the same field/command button descriptions as 
mentioned herein with respect to the Dialing Plan 
attributes section including: an "Item" field 3082 , 
e.g., including ID Code Set and ID Code Information; a 
"Value" field 3083; a "Set" field 3084 which designates 
the information displayed in the Attributes section is 
for the selected ID Code Set, which can be either in 
the ID Code Sets In Inventory or ID Code Set Updates 
sections; an <Undo> button 3085; a <Del Code> button 
3086 for deleting a selected ID Code; an <Add Code> 
button 3 087 enabling display of a further Web page 
including an Add ID Codes to Set window, such as shown 
in Figure 29 (p) ; and a <Close> button 3088 for closing 
the Add/Change ID Code Set Order window. 

As mentioned above, selection of the ID Code 
Sets "Retrieve" button 3065 in Figure 29 (n) enables a 
web page display of a Retrieve ID Code Sets from 
Inventory Window 3090 such as shown in the example web 
page display of Figure 29 (o) . From this window, a 
customer may specify search criteria or retrieve a 
predetermined amount of ID Code Sets having defaulted 
criteria. Particularly, the Retrieve ID Code Sets from 
Inventory Window 3090 comprises the following fields 
for retrieving ID Code Sets from customer inventory: a 
Set field 3091 enabling entry of the Set number; a 
description field 3 092 enabling entry of a full or 
partial ID Code Set description, e.g., alphanumeric 
description; an ID Code field 3093 enabling entry of a 
specific ID Code; a Quantity field 3094 enabling a 
customer to enter a value specifying the quantity of ID 
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Code Sets to include in the retrieval; an <Add> button 
3095 for updating the list box in the selected dialing 
plans section with the group information from the Set, 
Description, ID Code, and Quantity text boxes; a 
<Remove> button 3096 enabling a customer to remove a 
highlighted display item so that it is not included in 
the retrieval request <OK> button 3097 for accepting 
all entries in the Retrieve ID Code Sets from Inventory 
window, and messaging the host; and, a <Cancel> button 
3098 for closing the Retrieve ID Code Sets from 
Inventory window without accepting any changes. 

As mentioned above, selection of the Add Code 
button 3087 in Figure 29 (n) , enables display of the Add 
ID Codes to Set window such as shown in the example Add 
ID Codes to Set web page 3100 of Figure 29 (p) . As 
shown in Figure 29 (p) , the Add ID Codes to Set window 
3100 enables the customer to delete ID codes from a 
set; add ID codes one at a time, e.g., single 
generation; sequentially generate ID Codes to the Set; 
and randomly generate ID Codes to the Set. For 
instance, the customer may enter the set information in 
the following fields: the Set field 3102 for which the 
ID Code changes will take effect; a length field 3104 
setting forth the length of the ID Codes contained in 
the set; a description field enabling entry of text 
describing the set; and a type field indicating the set 
as local or global. With regard to the ID Codes 
generate options, a single generate option 3110 enables 
a user to add ID Codes one at a time to a set, e.g. by 
entering the number in the ID Code field 3112; a 
sequential generate option 3114 enables the user to 
specify a beginning ID Code number and a Quantity in 
entry fields (not shown) . The nMCI Interact ONM will 
automatically generate sequential ID codes according to 
the quantity specified by selecting the Add button 3118 
which updates a list box 3125 with information from the 
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generated id Codes; and, a random generate option 3120 
enables the user to specify a beginning ID Code number, 
an ending ID Code number, and, a Quantity in entry 
fields (not shown) . The nMCI Interact ONM will 
randomly- generate the specified number of ID codes 
within the beginning and ending range by selecting the 
Add button 3118 to update list box 3125, Selection of 
the <OK> button 3126 will enable acceptance of all the 
newly generated ID Code entries, messaging the host of 
the new codes, and, returning control to the Add/Change 
ID Code Set order page (Figure 29 (n) ) . 

As mentioned above with respect to Figure 
29 (a) depicting the nMCI Interact ONM web page display 
2764, the control menu option 2720 provides a refresh 
option which enables an update of all internal lists 
that have been altered on the host NetCap system. 
Specifically, the nMCI Interact ONM system 2700 updates 
the following lists: the network ID, Range Privilege, 
ID Code Set, Billing Location ID, Customer Service ID, 
location/access type, and, provisioning carrier. It 
should be understood that Refresh option will not 
change the values of an open window that includes data 
from one of the lists. 

Furthermore, with respect to the report menu 
option 2742 provided in the main web page display of 
Figure 29 (a) , users are enabled to inquire on their 
respective inventory for CPNs, Calling Cards, Dialing 
Plans, and ID Code Sets. The ONM system will display a 
respective "Retrieve" item from inventory, e.g., 
selection of report option for CPNs enables the display 
of the Retrieve CPNs from inventory screen as shown in 
Fig. 29(f). Particularly, in the ONM system 2700, four 
inventory reports may be provided to customers: CPN, 
Calling Card, Dialing Plan, and ID Code Set. Reports 
may be requested from the screen display of Figure 
29(a), however, will be delivered to the nMCI Interact 
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Inbox message center 270, for client viewing and 
retrieval in the manner as described herein. 



EVENT MONITOR 

As mentioned above, another application of 
the suite of telecommunications network management 
applications is the Broadband reporting system 850. As 
shown in the high level process flow diagram of Figure 
30 customers are enabled to request, specify, schedule 
and receive data reports relating to their Broadband, 
e.g., packet -switched, data networks. 

As shown in Figure 30, the Broadband ("BB") 
reporting system includes a Broadband view client 
comprising the client workstation component 20 
employing a web browser running, for example, Internet 
Explorer® 4.0 or greater, for enabling the generation 
of requests and receipt of responses from the Broadband 
system processes over the Web/Internet via a secure 
socket connection. As described herein, the StarWRS 
component 200 of the nMCI Interact system may be 
implemented to support Broadband report request, report 
retrieval, an alarm monitoring functions. All 
interactions with the Broadband reporting and system 
network management platform ("SNMP") features occur 
between the Broadband client applet 852 and a Broadband 
server 860. Particularly, Broadband application's Java 
classes invoke a "message class" that has the Common 
Object code as an interface definition. 

Integrated within the Broadband reporting 
system architecture 850 of Figure 30 is the nMCI 
Interact Web Server 24 and Dispatcher components 26 
which provides for the transport between the BB client 
browser and a Broadband proxy interface including all 

-177- 



WO 99/15979 



FCT/US98/20170 



authentication and encryption. Thus, secure 
communication from the customer browser to a DMZ Web 
server is enabled over a first secure TCP/IP socket 
connection, such as SSL, and, communication from the 
DMZ Web server over a corporate firewall to the 
Dispatcher server is enabled over a second TCP/IP 
socket connection, such as DES. These secure paths 
enable customer requests and server responses to be 
communicated between the client browser and the 
Broadband server 860. Specifically, the Dispatcher 
server 26 includes an integrated Broadband proxy 
application to forward user requests and responses 
to/from the Broadband server process 860 and to enable 
the Broadband functionality. As described herein, this 
proxy capability includes a multi- thread engine 
enabling multiple, simultaneously executing sessions 
supporting anticipated user load. The interface 
between the Dispatcher server and the Broadband proxy 
process is also message-based employing, e.g., TCP/IP 
socket transport, and, as will be described, a 
messaging protocol is defined that comprises a generic 
message header followed by proxy- specif ic data. For 
messages sent to the Broadband server, the generic 
message header is first sent followed by the proxy 
specific data. In the other direction, the same 
process is employed, i.e., the Broadband proxy sends 
the generic header followed by the proxy- specif ic 
response back to the dispatch server for communication 
over the firewall and back to the Web server. 

In the embodiment shown in Figure 3 0,. all 
Broadband responses including CSV data files are 
forwarded through the Dispatcher server 26 and 
intervening DMZ Web server 24 to the Broadband Inbox 
messaging server for subsequent access and eventual 
display at the client. 
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In the preferred embodiment, the Broadband 
("BB 11 ) server 860 performs the various database queries 
and function calls in response to requests received 
from the customer via the Broadband proxy 854. That 
is, the BB Client submits all requests and queries to 
the BB Server 860 using a generic proxy framework 
called BBProxyServer 854. These communications include 
Report requests, retrieval and viewing; requests for 
circuit information using SNMP Get commands; 
assignments of mnemonics for circuit names using SNMP 
Set commands; and, establishing a session to monitor 
alarm activities on circuits. Particularly, the 
Broadband server 860 is responsible for all tasks 
leading up to and including the generation of 
performance report and SNMP information including data 
collection, calculation, storage, and report 
generation. 

As further shown in Figure 30, the components 
feeding information to the Broadband server 860 
include: 1) a Performance Reporting System ("PRS" ) 
server 880 for sending performance and statistical data 
to the Broadband server; and, 2) the SNMP platform 870 
which is a tool that feeds real- or near real-time SNMP 
alarm and network event data to the Broadband Web 
server 860 via proxy interface 871. One such SNMP tool 
implemented by the assignee of the present invention is 
entitled "NetExpert 11 . The Broadband server 860 
additionally supports SNMP "get/set" functionality 
which is a menu -driven facility enabling a user to 
query the SNMP database for the value of a variable in 
a Management Information Base ( "MIB 11 ) 887, or, to set 
the value of certain variables in the MIB, as will be 
described in further detail hereinafter. 

The Broadband server 860 additionally 
supports communication with the StarOE component 39 
which provides order entry functions including 
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functionality necessary to manage (create, update, 
delete) Broadband users and, allows for a feed of the 
appropriate information to the Broadband server in 
order to associate the appropriate reports and 
Broadband functionality to the right customer once 
given admission to the Broadband service. As 
described, the StarOE order entry process essentially 
provides the means for authenticating users, and, 
initiating report generation. A messaging interface is 
provided between StarOE to the Broadband Web Server 860 
functioning as a client to receive authentication 
information and Bill ID and Level of service 
information which are supplied in response to launch of 
the Broadband applet. 

To establish Basic level reporting, the 
Broadband Server 860 transmits new customer information 
to the PRS1 component 880 when it is received. The 
customer Bill ID and circuit information are entered 
into the PRS1 tables via messaging interface 884. Any 
additions to or updates of User Name, User ID, Bill IDs 
are periodically passed from the Broadband Server 860 
to the PRS1 880 via FTP messaging interface 883 in 
response to the periodic, e.g. , nightly, updates to the 
Broadband server from StarOE. Particularly, the 
Broadband server 860 receives from the StarOE server 39 
a file containing all current BB customers with the 
following information: a date/time stamp; a username; a 
userid; a service level indicator; and, the number of 
billing ids and bill ids. For the level of service 
indicator, Broadband offers the following options: 1) 
Basic; 2) Standard; 3) Enhanced SNMP; 4) Premium; 5) 
Enhanced Ad hoc Reporting; 6) Enhanced SNMP + Ad hoc 
Reporting; and 7) Dedicated SNMP. Specifically, from 
the information downloaded from StarOE, comma separated 
value (CSV) reports are automatically created on a 
daily basis by the PRS1 from the inception of service 
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until service is discontinued. As an example, for the 
Basic level of service, the Broadband Server delivers 
three (3) CSV Files to StarWRS Inbox 270: Configuration 
report, Circuit usage, and PVC usage. 

Referring to Figure 31, the PRS device 880 
performs the following: 1) queries the MIB 887 on each 
switch via interface 886 for information about that 
circuit; 2) collects the data; and, 3) assembles that 
data in the appropriate tables for storage in the 
Broadband Server database 885. A nightly process 
between the RMS 872 and PRS database 280 synchs up PRS 
level of service information with the RMS 270 to 
determine what level of reporting is assigned to each 
circuit/PVC and runs the appropriate reports. From 
these components, the following functions, reports and 
capabilities are available to nMCI Interact users: a) 
near real-time performance statistics; b) customer 
performance reports including: 1) Frame Relay Graphs 
including: Network Health (Daily-Monthly) ; Network 
Throughput (Daily-Weekly-Monthly) ; Busy Hour Circuit 
Trend (Daily-weekly-Monthly) ; Customer Frame Delivery 
(Daily-Weekly-Monthly) ; PVC Utilization by Access 
Circuit Busy Hour (Daily-Weekly-Monthly) ; and Quality 
of Access Port by Hour (Daily) ; 2) Frame Relay Text 
Reports including: Network Throughput (Daily- Weekly - 
Monthly) ; Busy Hour Circuit Trend (Daily- Weekly- 
Monthly) ; Customer Frame Delivery Daily-Weekly- 
Monthly) ; PVC Utilization by Access Circuit Busy Hour 
(Daily-Weekly-Monthly) ; Quality of Access Port by Hour 
(Daily); and, Customer Configuration (Daily); 3) Frame 
Relay Downloads including: Circuit Usage (Daily) and 
PVC Usage (Daily) ; and 4) SMDS Graphs including Circuit 
Statistics (Daily-Weekly-Monthly) and Busy Hour Circuit 
Trend (Daily- Weekly-Monthly) . Additional capabilities 
include providing Near Real-time alarms and 
configuration reports (Frame and SMDS) relating to an 
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MCI customer's virtual transport network. Thus, the 
Broadband system 200 of the invention provides a tool 
set by which a customer can understand the performance 
of their virtual data network. It provides the 
customer with the ability to trend network performance 
statistics over time, and then to determine whether the 
network should be changed to ensure that it is 
operating at maximum performance levels (i.e., meeting 
business needs) . The Broadband reporting system thus 
enables customers to review network performance data 
over a period of time, e.g., up to 45 days, by creating 
and saving reports on their workstation, a network 
server, or a floppy disk. Alarm trending and analysis, 
correlating alarm occurrences to network availability, 
network performance and problem resolution may also be 
performed. 

A detailed flow diagram illustrating the CSV 
report creation process is now illustrated in view of 
Figures 30, 31, 32(a) and 32(b). As shown in Figure 
32(a), steps 902-906 depict the addition of the User 
Bill ID to PRS1, the addition of a customer's level of 
service information to StarOE and, addition of any 
report suppression information to the RMS . As 
described, level of Service information is available 
from the StarOE system. Level of service information 
from StarOE is of a courser granularity and is used to 
enable access to the appropriate Broadband 
capabilities, based on the order entry process. A user 
can suppress the transmission of a report or set of 
reports using the BB application, however, this does 
not stop the collection of performance statistics, only 
the generation of reports. 

The next few steps 908-914 relate to the data 
collection process. Specifically, data on the 
performance of all circuits associated with a 
particular Bill ID is collected from all switches in 
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the ATM or Frame Relay Network b an automated periodic 
polling process e.g., hourly. The addition of a new 
Bill ID to the PRS1 tables (step 902) is utilized by 
the polling process which process adds circuits and PVC 
5 to its polling requests based on association with the 

new Bill ID, as indicated at step 908. Then, as 
indicated at step 910, the poller queries the MIB 887 
on each switch in the network for statistics on 
selected circuits and PVC on a cyclical basis, e.g., 

10 every 15 minutes. As shown in Figure 31, the PRS 

poller function 896 polls the MIB 887 at each switch 
888 in the network, e.g., Frame Relay or ATM network, 
in sequence. The Poller sends a UDP packet to the MIB 
on each switch in sequence for statistics on all 

15 circuits/PVCs enabled for Broadband service. In 

response to the UDP request, at step 912, the MIB 
returns all the current statistics on circuit/PVC data 
from the switch. In the event that a switch is not 
reachable, the polling process logs an error in a PRS1 

20 error log indicating that the specific switch was not 

reachable. Next, as indicated at step 914, the PRS1 
writes the data to a text file and a Sybase bulk loader 
process adds the information to a raw data table. 
Particularly, as shown in Figure 31, a PRS assembler 

25 process 897 distributes statistics to the appropriate 

tables in a PRS1 active database 880. The assembler 
process compares the previous hour's data to the data 
in the raw table, compares values and writes the deltas 
to the hourly tables, which tables are then replicated 

30 to the reporter. 

Then, in Figure 32(a) at step 916, an 
automated process runs selected reports on available 
statistics in the PRS database tables. In the 
preferred embodiment, as shown in Figure 31, this 

35 reporting process 298 occurs nightly, however, it can 

be run on any periodic basis. The specific reports that 
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are run are determined by the level of service for 
which the Bill ID is enrolled as stored in StarOE 
tables . 

Referring to Figure 32 (b) , as indicated at 
step 922, for each Bill ID, the reporter determines 
which reports are to be produced, generates queries 
against the appropriate tables, runs the queries at the 
appropriate time and delivers reports to the users BB 
InBox 270. Report creation is done in sequence: all 
dailies, then all weeklies (if appropriate) then all 
monthlies (as appropriate) . Particularly, as indicated 
at steps 92 5 and 927, a control process 

11 s RunAl 1 Reports 11 is invoked to load all customer 

lists, and at step 925 calls "s_GenReport u which 
collects level of service information for all 
customers. As indicated at step 928, the RMS process 
returns level of service information indicating any 
report suppression, and, at steps 929, the 
"s_GenReport" creates and executes queries against the 
data collected in the PRS1 database. At step 930, 
result sets are written to a temporary report directory 
and are then compresses at step 933 and added to the 
PRS database which may store the report for a 
predetermined amount of time, e.g., one week. Next, as 
indicated at step 935, the reports are replicated using 
off-the-shelf components, e.g., Sybases 1 s RepServer, 
and saved on a Broadband server report location 
database ("RLD") 885 which can be remote mounted by the 
Broadband Server 860. Particularly, the PRS reporter 
29 8 shares a drive on which these reports are located 
with the Broadband Server via a remote file mount. The 
Broadband Server database retains data and reports for 
a predetermined period of time, e.g., 45 days, prior to 
the current data. 

Finally as indicated at step 93 8, the 
Broadband Server 860 determines which reports have been 
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produced and forwards them directly to of with the 
Broadband Inbox component associated with the Bill ID. 
Broadband Server creates a unique filename for each CSV 
report and places each report on the Broadband Inbox 
5 270 (Figure 30) for customer retrieval, as indicated at 

step 940. The steps of 922-938 are depicted in a 
condensed physical architecture diagram of the 
Broadband system shown in Figure 31. 

As shown in Figure 32(b) at steps 925-927, 

10 933-935 a determination is made as to whether the 

processing performed in each step was successful. If 
the processing performed in each step was not 
successful, or, an error occurs, then the error may be 
logged in a log file 939 at the Broadband Server and at 

15 Inbox for subsequent review, when necessary. 

Details of the Broadband report retrieval 
process 950 is now described in view of Figure 33. It 
is assumed that StarOE has already validated the user's 
id and password, and that the user is entitled to 

20 receive Broadband services. Thus, upon selection of 

the Broadband Services icon 93 from the nMCI Interact 
home page (Figure 5 (b) ) the user may enter into the 
Broadband Services system and particularly, to access 
the Broadband Client front end. A client Broadband 

25 applet is thus, downloaded to the customer who is 

presented with the Broadband main display screen, as 
indicated at step 952. 

An exemplary Broadband web -page BB Main 
Display screen 1720 is shown in Figure 34 (a) which 

30 presents a variety of user- selectable Broadband options 

including: 1) an Inbox option 1722 enabling a user to 
retrieve their Broadband reports; 2) an option 1724 
enabling a user to view SNMP alarms; 3) an option 1726 
enabling a user to specify reports to be suppressed; 4) 

35 an option 1728 enabling a user to retrieve Broadband 

reports that have been archived; 5) an option 1730 
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enabling a user to receive information regarding their 
circuit locations; 6) an option 1732 enabling the 
"get/set" functionality for providing meaningful labels 
to circuit locations to improve report readability; 
and, 7) an option 1734 enabling the retrieval of a map 
viewer application for generating maps portraying the 
customer's virtual networks. 

In the preferred embodiment, a Broadband Main 
Display applet is provided as a launching pad for 
accessing all of aforementioned Broadband services. 
The Main Display applet is preferably a Java applet 
running inside the user web browser 20 and utilizing 
classes which extend the basic Java applet 
functionality in areas such as application management, 
user session management, user- interface, inter- applet 
communication, and client/server communications. 
Particularly, from the Broadband Main Display applet 
access to and communications between Broadband 
applications is provided using the Common object 
COApplet, COApp, and COBackPlane services which are 
objects functioning in the manner as described herein. 
In the manner as shown in Figure 3, the Main Display 
applet BBMainDisplay inherits front COAppIMPL class 
with a COApplet interface and is launched from the nMCI 
Interact COBackPlane using the COApplet interface. 
When a user clicks on a Broadband service toolbar 
button or menu item, BBMainDisplay creates an instance 
of a COApp (let) to manage the corresponding 
application. When the user exits from Broadband 
services, the COBackPlane is utilized to destroy the 
application and its windows. 

The Broadband Main Display applet provides a 
menu-bar, toolbar, and status bar tor accessing 
Broadband services according to the customer's 
subscribed service option which includes: Basic; 
Standard; Enhanced SNMP; Premium; Enhanced Ad hoc 
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Reporting; Enhanced SNMP + Ad hoc Reporting; and 
Dedicate SNMP. As determined by the user logon session 
with the StarOE server 260, if the user is not 
entitled or does not have authorization for a 
particular service, the corresponding toolbar icon or 
menu item is disabled (ghosted-out) and will be 
rendered insensitive to user input in accordance with 
the customer service option. 

When BBMainDisplay is launched, the Main 
Display first determines the user's Broadband level of 
service option, e.g., Basic, Standard, Enhanced SNMP, 
etc. A user selects a Broadband service, e.g., custom 
reporting, archive reporting, or SNMP features such as 
Get/Set and alarm panel by clicking on the 
corresponding tool bar icon or pull -down menu item on 
the Main Display applet (Figure 34(a)). For the case 
of custom (Ad hoc) reporting of data, e.g., from the 
Frame Relay MIB, a custom reporting applet interface is 
provided. From this web interface, a customer can 
select from the available data variables (i.e. physical 
or logical circuit, data point value, time frame for 
report, etc.). Specific responsibilities of the custom 
report applet include: 1) allowing customers to define 
a custom report query using single performance 
statistics category, statistics range, and date/time 
range; 2) allowing customers to select reports 
presenting statistics relating to their current network 
Access Circuits or network PVCs. This comprises 
enabling a customer to select either Access Circuit or 
PVC reporting category type, in which case a drop down 
list displays current performance statistics for the 
selected category. The Customer then selects a single 
performance statistics category from drop down list; 3) 
allowing a customer to specify range on statistic value 
using relational operators and numerical values, e.g., 
value >=80%; 4) allowing a customer to specify report 
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date/time range covering, for example, the previous 45 
days of service. A customer can select start and stop 
date/time anytime within range; 5) allowing the 
customer to save the custom defined queries by 
providing a "Save Query" option; and, 6) providing an 
"Auto Run" function to allow custom reports to be run 
automatically and available when the default reports 
are produced through the Broadband Inbox. Once the 
user submits the custom report request it is forwarded 
to the Broadband Inbox for subsequent view. 

When basic service option is provided, the 
Broadband main display applet has the responsibility 
of: 1) requesting service type (entitlements) either 
from StarOE authentication server or as data from 
BackPlane (Figure 3) ; 2) requesting reports that are no 
longer on the Inbox server to be retrieved from a 
report data archive if a pre -determined period of time 
has elapsed, e.g., 45 days, and provide these reports 
to the customer via the Broadband Inbox; 3) defining 
how the customer reports should be requested, e.g. 
report ID, date, etc.; 4) providing on-line context 
sensitive help for all aspects of the Broadband WEB 
application; 5) providing access to the Broadband 
User's Guide; 6) providing the ability to spawn 
separate dialog windows, for example, to explain 
reporting activity in progress; 7) providing a "send 
mail" function to provide the customer with a method to 
create a mail memo for distribution to a help desk; 
and, depending upon the customer's service option, 8) 
providing access to custom reporting capability (Ad Hoc 
Reporting) via toolbar and menu; and, 9) providing 
access to the SNMP features (Get/Set and Alarm) via 
toolbar and pull -down menu. 

Referring back to Figure 33, the user may 
select the BB Inbox feature as indicated at steps 9 54a- 
954c by clicking on the BB Inbox icon. By clicking the 



-188- 



WO 99/15979 



PCI7US98/20170 



BB Inbox icon a download of the BroadBand Inbox applet 
is initiated, as indicated at step 956. Via this 
applet, the BroadBand View Inbox client requests all 
available report data (headers) from the Report 
Location Database as indicated at step 958. Then, at 
step 960, the RLD returns header information such as 
report name, id, location, date/time requested , data 
time produced to the client, and uses the information 
to autopopulate the entries in the Broadband Inbox at 
step 962. The report availability is then displayed 
in the BB Inbox (client) screen at step 964. It 
should be understood that by the time a user has 
received the welcome packages from nMCI Interact, 
backend data collection any report generation 
activities at the appropriate level of service have 
already begun. As a result, completed reports are 
available at the first login. 

Figure 34 (b) depicts an example Broadband 
view Inbox screen display 1740 having a screen area 
1745 for displaying the currently available reports. 
Referring back to Figure 33, a user may retrieve any 
report for viewing by double clicking on the report 
desired which action causes a request for the report 
and the appropriate viewer to be sent to the BroadBand 
Server, as indicated at step 968. BroadBand Server 
responds by locating the file (using the RLD) and 
transferring the file to the user and the appropriate 
viewer to the client. In the preferred embodiment, the 
user is enabled to display comma separated values 
("CSV") textual reports, as indicated at step 971; 
network health multigraph reports, as indicated at step 
972; and, map reports, as indicated at step 973. 

Thus, in the preferred embodiment, the 
Broadband Report Viewer component includes Java applet 
viewer classes that enable the downloading and display 
of performance reports generated from the Broadband 
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server 860. In the preferred embodiment, there are at 
least two types of viewer classes providing the 
following reports: 1) Monthly Network Health Reports 
which are static standard and multi- graph reports 
5 having three information areas: i) domestic latency, 

i.e., network delays; ii) delivery, i.e., network 
throughput; and iii) Peak Utilization, e.g., based on 
committed information rates; and, 2) Daily Network 
Health Reports which are static standard and multigraph 

10 reports having the domestic latency, delivery and Peak 

Utilization reporting views, in addition to a fourth 
reporting Exceptions view. Besides having the ability 
to select reports on a daily or monthly basis, a custom 
reporting Java applet is provided to enable customers 

15 to select Broadband "Ad hoc" (one time) reports at any 

previously defined interval. For example, a customer 
may have a standard "Daily Throughput Performance" 
report delivered each day. However, for a particular 
day, the same customer may choose to submit an ad hoc 

20 "Throughput Performance" report for a previous time 

interval, e.g., previous week, or previous month. In 
the preferred embodiment, the Broadband web server adds 
completed report data in CSV to the Broadband Inbox 
server 270 which component enables the client reporting 

25 viewing process 215 to display reports. Particularly, 

the BB client application loads the report viewer, 
which loads the requested report and displays it to the 
user. For CSV/ spreadsheet reports the user has the 
option to manipulate the data in the viewer, when 

30 viewing multi-graph reports such as the Network Health 

report, the viewer provides drill down capability: by 
double clicking on a section of a graph, the supporting 
data is displayed. 

The Broadband Report Viewer component 

35 additionally includes Java applet classes enabling the 

display of customer configuration maps which are two 
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dimensional maps having certain locations highlighted, 
e.g., customer gateways, in addition to lines 
connecting two or more locations representing a 
customer's dedicated data transport paths, e.g., 
5 permanent virtual connections ("PVC"), as will be 

hereinafter described in further detail. Besides 
having the ability to generate network performance 
reports and configuration maps, the Report Viewer 
component of the Broadband Reporting tool includes Java 

10 applet classes enabling the presentation of real - or 

near real - time alarm and network event data obtained 
from the network management platform, "NetExpert" 870 
as shown as Figure 31. Via a proxy application 871, 
events and alarm notifications are sent to the BB 

15 server 860 which processes the alarms for communication 

through the dispatcher/BBProxyServer applications 
directly to the BB client 852, via secure TCP/IP socket 
messaging, as will be described in greater detail 
hereinafter. 

20 Referring back to Figure 34(a), the selection 

of the report suppression option 1726 will enable the 
presentation of a BB view report suppression screen 
1750, an example screen of which is shown in Figure 
34 (c) . From this screen, the user is enabled to 

25 suppress or enable the particular selected report name, 

type, schedule, by selecting pull -down menu 1755. 

Furthermore, as shown in Figure 34(a), the 
selection of the archive option 1728 will enable the 
presentation of a BB view archive report screen 1760 an 

30 example screen of which is shown in Figure 34 (d) . From 

the screen of Figure 34 (d) , the user is enabled to 
select the archived report to be displayed at the 
BB Inbox by name, type, scheduling period, and 
reporting time period in entry fields 1769. 

35 As further shown in Figure 34(a), the 

selection of the circuit location option 1730 will 
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enable the presentation of a BB view circuit location 
screen 1762 an example screen of which is shown in 
Figure 34 (e) . From the screen of Figure 34 (e) , the 
user is enabled to retrieve network configuration 
information pertaining to that customer's network by 
clicking the appropriate circuit id and location field 
from a list 1763. By clicking on this field, a textual 
report containing circuit configuration information may 
be displayed. The preferred method of reporting to a 
customer the current configuration of their MCI 
supplied virtual data network is via a web base 
geographical image map. The Broadband mapping report 
and Customer Configuration Map report are available for 
customers of all levels of service via the Broadband 
reporting system. 

Preferably, all Broadband customers receive a 
basic report set containing information on utilization, 
throughput and treatment of data transmitted over their 
virtual data networks as part of the default report set 
for the selected service option. Each service, e.g., 
SMDS and Frame Relay option, is provided reports 
specific to the performance indicators of that service 
(e.g. utilization, throughput and treatment of data 
transmitted over the virtual data network). The actual 
reports and the reporting interval may be unique, based 
on the type of report although default reports are 
available. A Customer Configuration text report is 
included within a default set of reports. The mapping 
report is preferably updated on a daily basis based on 
changes that have occurred within the customer's 
network in the previous 24 -hour period. As the update 
is dependent upon a successful completion record, 
update latency can be greater than 24 hours from the 
actual event causing the change. 

The data source for the customer's 
Configuration Map and Customer Configuration text 
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reports includes: a customer name; Billing id; contact 
(name and phone number of customer representative for 
this account ); customer's mailing address; and the 
company providing FR service, e.g., MCI; a location 
field comprising a mnemonic identifying the MCI point 
of presence (POP), i.e., the city and state where the 
circuit is located; a circuit name assigned in circuit 
order management system for customer's FR access; a 
gateway field containing a mnemonic identifying the 
gateway that services this circuit; a Network Mgt. ID 
field that identifies the "NetExpert" system (Figure 
30) address by gateway, slot, port, and channel in the 
router card cage for this circuit; a Bandwidth field 
indicating circuit speed; a # PVC field indicating the 
Number of PVCs associated with this circuit (circuit 
name) a CIR total field indicating the sum of the CIRs 
for all PVCs on this circuit; an OVR SUB (%) field 
indicating the CIR Total (above) divided by the 
bandwidth times 100; a PVC field indicating a PVC 
number; a Gateway field comprising a mnemonic 
identifying the gateway that services circuit on the A 
side of the PVC; a Circuit field indicating the circuit 
name assigned to the A side of the PVC; a DLCI field 
indicating the DLCI assigned to the A side of the PVC; 
a CIR field indicating the CIR for the A side of the 
PVC; a Gateway field comprising a mnemonic identifying 
the gateway that services circuit on the B side of the 
PVC; a Circuit field indicating the circuit name 
assigned to the B side of the PVC; a DLCI field 
indicating the DLCI assigned to the B side of the PVC; 
and, a CIR field indicating the CIR for the B side of 
the PVC. 

As mentioned above, the BB Report Viewer 
component includes the capability of displaying maps. 
The Map viewer displays all available (BB enabled) 
circuits provisioned for the user. Clicking on a 
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circuit enables a display of the latest statistics for 
the circuit. . All display functions including sorting, 
saving to disk and printing the report are executed by 
the viewer locally. 

In the preferred embodiment, there are two 
graphical views of the configuration report to support 
both the Standard and Enhanced service level options: 
Figure 35(a) illustrates the first map view 1770 which 
presents a two dimensional map of the United .States 
with all end points of a customer's virtual data 
network represented with an indicator 1775, e.g. a 
star; Each star represents a customer's circuit end 
point location within an MCI data network, but may also 
indicate non- domestic frame relay, SMDS or LEC access 
end points. As shown in the Figure 35(a), selection of 
the "View all PVC's" button 1778 enables the 
presentation of all circuits supported in the network. 
A second map view 1776 may also be displayed such as 
shown in Figure 35(b). From this view, the customer 
may drill down on a selected endpoint by clicking on an 
identified location 1777 and receiving a changed view 
(text box) that includes a description 1779 of the 
physical circuits supported by that network end point. 
Thus, a click on any identified point provides greater 
detail about the circuits supported from that end point 
including: circuit location; Circuit number; Gateway 
mnemonic; Network Management ID; Bandwidth; # PVC; and, 
CIR Total. As shown in Figure 35(b), lines connecting 
PVC end points are also drawn by a mouse click on an 
identified end point. In the preferred embodiment, map 
views of Figures 35(a) and 35(b) are supported by 
invocation of Java applets which have the advantage 
that an image map implemented as a Java applet provides 
instant feedback to users. When a user clicks on a map 
displayed by a Java applet, the applet locally 
computes a response to the click and instructs the 
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browser to load a new page. 

Referring back to the report retrieval 
process flow 400 illustrated in Figure 33, at step 964 , 
the customer is further enable to delete a report by 
selecting the delete report option. 

To delete a report, the user highlights the 
report in the Inbox listing (Figure 34(b)) and selects 
a delete function, as indicated at step 966. In 
response, at step 970, the client submits a delete 
request to than BB Inbox Server which locates the 
report, logs the request, deletes the file, and returns 
an acknowledgment to the client, as indicated at step 
974. Upon receipt of the acknowledgment, the Inbox 
client refreshes the display to reflect the deletion. 
Errors in the deletion activity result in an error 
message which is logged at the server, and returned to 
the Inbox client. In response, the client may notify 
the user of the deletion failure by a pop -up dialog box 
on screen. 

For the case of accessing SNMP capabilities, 
an SNMP application is launched from the Broadband SNMP 
Main Display Application if the customer has the SNMP 
dedicated or PRS Enhanced service option. Specific 
responsibilities of the SNMP application include: 1) 
providing SNMP Get/Set operations including: obtaining 
the selected variables from the Enterprise MIB upon 
initialization; 2) communicating with BBProxyServer and 
Broadband server database; 3) invoking Get/Set 
operations on MIB and returning results and displays; 
4) providing an Alarm Panel for displaying alarms and 
event reporting; 5) handling customer near real time 
notification of updates to these alarms if the 
customer's web browser is pointed to a Broadband web 
page; and, 6) providing customer with SNMP get 
capability for the lowest interval data, e.g., 15 
minutes to 1 hour. 
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Thus, as further shown in Figure 34(b), the 
selection of the SNMP Alarm option 1724 enables the 
presentation of a BB alarm panel screen 1765 an example 
screen of which is shown in Figure 34(f). From the 
screen of Figure 34(f), the user is enabled to retrieve 
and view their virtual network alarm conditions 
including the following indications: an alarm type; 
circuit id; alias; alarm severity level; alarm trap 
level; alarm description; and, date of the alarm. 

In one embodiment, as shown in Figure 34(f), 
the alarm data is handled by listing all of the PVCs 
and the associated Access Circuits as well. For each 
PVC and Access circuit all relevant events and alarms 
will be displayed. Preferably, color coding is used 
for indicating alarm severity in compliance with OSI 
standards, e.g., orange for major, red for critical. 
In the preferred embodiment, Broadband alarms may be 
grouped into two categories: Network Detected alarms 
and User Defined alarms. Network Detected alarms 
include: "Set alarms" that are generated when a 
condition exists indicating service degradation or 
failure, and "Clear alarms" which are generated when a 
previously set alarm condition no longer exists. 
Particularly, in order for alarm data to be updated, 
the alarm collection server process invokes two methods 
on BBProxyServer : 1) a "recordAlarm" method which 
records an alarm and writes the alarm data to the 
database; and 2) a "clearAlarm" method which clears an 
alarm and removes it from the database. 

It should be understood that all Network 
Detected Alarms are event -based and discovered by SNMP 
Network Management tool. User Defined Alarms include 
"Ad -Hoc Threshold" alarms which are generated in 
instances where a customer set value in a custom report 
is exceeded. The alarms are generated as the reports 
are updated, based on the polling frequency, and only 
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when the customer set threshold is exceeded. User 
defined alarms additionally includes SNMP alarms which 
are generated when a customer defined alarm condition 
exists based on the SNMP service, 

Assuming that order entry for the user has 
been completed and the user is provisioned with a level 
of service which includes SNMP functionality, the user 
has additional access to SNMP functions Get and Set. 
The Get and Set represent paired functionality which is 
accessed when the user selects the SNMP Get/Set option 
1732 from the BroadBand View Main Display of Figure 
34(a), The selection of the SNMP Get/Set option 1732 
enables the presentation of a BB SNMP Get/Set screen 
1731 an example screen of which is shown in Figure 
34(g). From the screen of Figure 34(g), the user is 
enabled to: Get SNMP statistics and Set SNMP name. 

Particularly, the process flow for providing 
SNMP Get/Set capabilities begins by invocation of an 
SNMP applet which is sent to the client workstation by 
the BB Server application. By selecting the SNMP 
Get/Set button 1732 (Figure 34 (a) ) from the main 
display causes the creation of a SNMPGetSetApp (COApp) 
object to manage the session and create a series of 
objects, SNMPGetSetFrame, SNMPGetSetView, 
SNMPGetSetModel and SNMPGetSetController to handle the 
presentation to/interaction with the user. This also 
results in the presentation of the get/set display 
window (Figure 34 (g) ) having a dialog box 1731 
presenting the user with the customer, PVC or circuit 
to be queried. Particularly, the SNMP client stub 
invokes the following BBProxyServer methods for 
populating the dialog box with the PVC and circuit 
information: 1) a getSnmpCategories () method for 
communicating the request to retrieve SNMP variables 
from the MIB; 2) a "getPVCList ()" method for returning 
a list of customer PVC's; and, 3) a "getCircuitList ( ) 99 
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method for returning a list of customer's access 
circuits, i.e., circuit IDs. Preferably, the 
appropriate service is invoked on BBProxyServer , the 
BroadBand .database is queried and the results are 
returned to the customer browser for display. The user 
selects the desired SNMP category 1733, e.g., customer, 
PVC, or access circuit, to be queried. For instance, 
as shown in Figure 34 (g) , the selection of the PVC 
Statistics category 1733 will enable the variable list 
box 1735 to be updated with a list of only those 
variables from the selected category. 

When a SNMP variable "GET" operation is 
desired, the user selects the particular SNMP variable. 
Then, the user invokes the get operation by selecting 
the GET button 173 8 from the Get/Set display of Figure 
34(g). Selection of the GET button causes the SNMP 
client stub to invoke the BBProxyServer side 
"getAt tribute" method which returns object <String>, 
the string being an SNMP attribute name, to the 
customer browser. By invoking the "getAttribute" 
method, the request is submitted to the BB server and 
communicated to the MIB to retrieve SNMP attributes, 
e.g., circuit and PVC statistics. The MIB obtains the 
latest SNMP data, transfers the data to the BB server, 
and returns control to the BB Client which handles the 
display of the data to the customer (Figure 34 (g) ) . 
Particularly, the BB server issues a GetService request 
in turn to the MIB on the appropriate switch (es) . The 
MIB locates the latest polled status information and 
returns the data to the server, which passes the data 
back to the client with a GetService Response message. 
Upon receipt of the data, the client closes the thread 
and updates the display. Finally, the user may submit 
requests for SNMP variables from other circuits, or, 
may end the session. Likewise, when the user wishes to 
Set a circuit name, the user first selects the 
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particular SNMP variable and further, enters the 
"alias" variable value for the selected SNMP circuit . 
This "alias" variable value is entered in the "value" 
entry field 1737 as shown in Figure 34(g). Then, the 
user invokes the set operation by selecting the SET 
button 1739 from the Get/Set display of Figure 34(g). 
Selection of the SET button causes the SNMP client stub 
to invoke the BBProxyServer side "setAttribute" method 
which updates the selected SNMP variable in the 
Broadband database sets. By invoking the 
"setAttribute" method, the request is sent to the BB 
server which issues a setServiceO request to the MIB 
on the appropriate switch (es) . The MIB changes the 
(user defined) alias assigned to the circuit and 
returns an acknowledgment to the server, which passes 
it to the client with a SetService Response message. 
Upon receipt of the data, the client closes the thread 
and updates the display, acknowledging that the circuit 
name has been changed. Finally, the user may submit 
new requests to set SNMP variables from other circuits, 
or, may end the session. As in the case of Broadband 
network systems reporting, the nMCI Interact suite of 
network management applications further includes an 
event monitor tool 1000 for enabling customers to 
monitor, over the Internet or a company Intranet, their 
dedicated voice and data circuits. A Web-based user- 
friendly interface presents network alarms on degraded 
or broken circuits and provides network performance and 
alarm information, thereby effectively increasing the 
efficiency of troubleshooting and allowing customers to 
make informed network management decisions. 

More specifically, the Event Monitor tool 
1000 of the nMCI Interact System gives customers the 
ability to: exercise alarm management from a single 
workstation, the management including, triggering the 
alarms and clearing the events; acknowledge or 
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recognize new alarm conditions as they occur; receive 
notification of fiber outages that impact their data 
circuits; define or display customized troubleshooting 
procedures for specific alarm or circuits; access a 
comprehensive database of their dedicated voice and 
data circuits; display or print lists of active alarms ; 
define or display customized alarm filters to specify 
which alarms will appear in the alarm presentation; and 
generate reports about network performance. 

A general block diagram illustrating the 
event monitor system architecture 1000 is shown in 
Figure 36. Generally, as shown in Figure 36, the Event 
Monitor system 1000 is integrated within the nMCI 
Interact system comprising: the user web browser 14 
which employs an event monitor GUI 1030 enabling the 
generation of requests and receipt of responses from 
various event monitor system server processes 1050 over 
the Web/Internet via a secure socket connection for 
presentation of event monitor's alarms and reports; 
report viewer 215 and requestor processes 212 (Figure 
10) of the StarWRS tool 260 which provides the support 
for generating and presenting reports relating to the 
conditions of the customer's voice and data networks as 
described herein; a corresponding server side reporting 
component having the above described inbox, report 
scheduler and report manager components, in addition to 
alarm and report viewer and requestor components 
implementing Java applets having viewer classes that 
enable the downloading and display of performance 
reports generated from event monitor server processes 
105. In the preferred embodiment, the viewer classes 
provide the following types of network alarms on 
dedicated circuits that carry the following service 
types: inbound services, e.g., toll free and 900 
numbers; outbound services, e.g., Vnet/Vision, and 
PRISM; and data services such as TDS 1.5. The circuit 
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types for which the present invention presents network 
alarms include: dedicated access lines such as DALs; 
TDS 1.5 circuits; TDS45 circuits, DDS/DSO point to 
point circuits; ISDN DALs; and SW 56 DALs. In 
addition, the event monitor reporting feature enables 
customers to review alarm data over a period of time by 
creating and saving reports. The reports which may be 
generated include alarm summary, alarm detail, alarm 
duration, data circuit performance, and DAL 
performance. The alarm and performance reporting 
scheme effectually allows the customers to perform 
alarm trending and analysis, and to correlate alarm 
occurrences to network availability, network 
performance and problem resolution. Reports for fault 
reporting may be requested through the report requestor 
component of StarWRS, and retrieved from the STarWRS 
inbox. Recurring reports may be requested on a timely 
basis, e.g., hourly, daily, weekly, and monthly. 
Moreover, through the report requestor, a user may 
specify whether the user should be paged or e-mailed 
when a report is in the inbox. 

It should be understood that the event 
monitor tool may be integrated with the Broadband 
network reporting service to provide a comprehensive 
network performance reporting and alarm monitoring 
system. 

Also shown as part of the event monitor 
system architecture 1000 of Figure 36 is the web 
server/dispatcher component 1035 which provides for the 
transport between the web browser and an event monitor 
proxy interface including all authentication and 
encryption. Thus, secure communication from the 
customer browser to a DMZ web server is enabled over a 
first TCP/IP socket connection, such as SSL, and 
communication from the DMZ web server over an 
enterprise firewall to the dispatcher server is enabled 
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over a second TCP/IP socket connection. These secure 
paths enable customer requests and server responses to 
be communicated from the client browser to the event 
monitor server 1050. 

Specifically, the dispatcher forwards user 
requests to the event monitor server process 1050 that 
employs an integrated proxy application 1040 for 
receiving and interpreting the user messages and 
enabling the event monitor functionality. This proxy 
capability includes a multithreaded engine enabling 
multiple, simultaneously executing sessions supporting 
anticipated user load. The interface between the 
dispatcher server 1035 and the event monitor proxy 
process 1040 is also message -based, e.g., employing 
TCP/IP socket transport, and, as will be described, a 
defined messaging protocol which includes a generic 
message header followed by proxy- specif ic data. In the 
other direction, the same process is employed, i.e., 
the event monitor proxy 1040 sends the generic header 
followed by the proxy- specif ic response back to the 
dispatch server 1035 for communication over the 
firewall (not shown) and back to the user browser 20. 

In the embodiment shown in Figure 36, the 
necessary CSV data files and report definition metadata 
files may be downloaded to the StarWRS inbox messaging 
server 270 for eventual presentation to the StarWRS 
browser- side components 212, 215 for subsequent access. 
It should be understood, however, that all event 
monitor responses including CSV data files and report 
definition metadata files are forwarded through the 
dispatcher and intervening DMZ web servers for eventual 
display at the client. Additionally, the event monitor 
may return a report object of variable length which 
includes the report data to be displayed at the client 
workstation. 
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In a preferred embodiment, the event monitor 
server 1050 performs the various database queries and 
function calls in response to requests received from 
the customer via the event monitor proxy 1040. 
5 Particularly, the event monitor server 1050 is 

responsible for all tasks leading up to and including 
the management of alarms and performance reports 
including data collection, calculation, storage, and 
report generation. 

10 In operation, the event monitor server 1050 

supports communication with the StarOE server component 
39 which provides order entry functions including 
functionality necessary to manage (create, update, 
delete) event monitor users, and allows for a feed of 

15 the appropriate order entry information to the event 

monitor server in order to properly associate the 
appropriate event monitor functionality and data to the 
right customer once given admission to the event 
monitor service. Thus, a messaging interface is 

20 provided between StarOE 39 to the event monitor server 

1050 functioning as a client to receive authentication 
information including logon user identifiers which are 
supplied in response to launch of the event monitor GUI 
applet 1030. The billing identifiers and levels of 

25 services, including the specific entitlement 

information are supplied from StarOE 39 to the event 
monitor server 1050 via flat files which may be 
generated daily. 

From the back-end legacy host, the event 

30 monitor server 1050 receives statistics on voice (DAL) 

and data (TDS 1.5) services for providing its 
functionality to the event monitor users. The DALs are 
groups of dedicated 64K circuits that carry voice 
traffic to and from a customer's premise terminating 

35 equipment, i.e., PBX, to a telecommunication service 

provider's switch. A TDS 1.5 data circuit is a 
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customer location directly to another. The data 
circuit includes at least two monitoring units, called 
Extended Superframe Monitoring Units (ESFMUs or ESF 
Cards) , which generate alarms and collect statistics on 
the performance of the circuit. Alarms are presented 
near real-time and indicate that there is a failure 
associated with the data circuit. Performance 
statistics are compiled in 15 -minute intervals and are 
used to derive performance alarms that provide the 
users with the indication that their network 
performance is degraded before the problem becomes 
service impacting . 

Performance statistics are compared against 
preset performance parameters and deviations. from these 
parameters are recorded. When a given threshold is 
exceeded, alarms are generated and, notification is 
sent to the customers such that the customers may then 
view alarms and take necessary steps to correct the 
problem. The performance parameters and thresholds may 
be modifiable via the event monitor GUI applet 1030 by 
those customers having proper access level entitlements 
as verified by the StarOE 39. Each of the components 
shown in Figure 36 and their respective processes will 
be described in further detail herein. 

Event monitor GUI client application 

All alarms and reports for event monitor are 
accessible via the "networkMCI Interact" alarming and 
reporting structure established within the nMCI 
Interact home page 79. Event monitor alarms are viewed 
via an alarm monitoring system in which both broadband 
and event monitor alarms may appear. The event monitor 
GUI client application is launched via the event 
monitor icon 87 on the home page (Figure 5(a)). 
Reports for fault reporting may be requested through 
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the report requestor component of StarWRS, and the 
inbox server. 

In the preferred embodiment, the event 
monitor GUI client application 1030 is launched by 
selecting the event monitor icon 87 from the 
"networkMCI Interact" home page- (Figure 5(a)). The 
event monitor GUI client application provides a menu 
bar, toolbar, and status bar for accessing event 
monitor services depending on the customer's service 
subscriptions. Event monitor service availability is 
determined by user logon session with StarOE server 
1060. If the user is not entitled or does not have 
authorization for a particular service, the 
corresponding toolbar icon or menu item is disabled. 
Thus, in accordance with the customer service option, 
the corresponding service icon and/or menu item is not 
activated and would not respond to a user input. 

In providing its basic services, the event 
monitor display applet may have the responsibility of: 
1) requesting reports that are no longer on the inbox 
server to be retrieved from a report data archive if a 
pre -determined, period of time has elapsed, e.g., 45 
days, and provide these reports to the customer via the 
inbox; 2) defining alarm thresholds and parameters and 
trouble shooting procedures; 3) defining how the 
customer reports should be requested, e.g., report id, 
date, etc.; 4) providing on-line context sensitive help 
for all aspects of the event monitor web -based 
application; 5) providing the ability to spawn separate 
dialog windows, for example, to explain reporting 
activity in progress; and 6) providing access to custom 
reporting capability via the toolbar and menu. 

In the preferred embodiment, the event 
monitor GUI application is implemented in Java to 
ensure platform independence and particularly is 
developed using many of the networkMCI Interact ' s 
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common objects as described herein. Particularly, the 
Event monitor GUI application, via the COApp object, 
may create its own display space and present its user 
interface in a separate frame by having the space in 
5 one or more COAppFrame windows. The COAppFrame class 

and its COAppFrame subclass are wrappers for the Java 
Frame class which provide COApps with standard look- 
and- feel elements and implement some standard behavior, 
such as participating in COBackPlane 1 s window 

10 management functions. The COAppFrame is a desktop 

window, separate from the browser. It presents the 
user with a preset layout of a menu, toolbar, status 
bar, enterprise logo, an application icon, etc., and a 
main viewing area. Since a separate frame does not 

15 need to be located inside a Web page, a concurrent 

(side-by- side) access to more than one networkMCI 
Interact application service is possible. 

In another embodiment, the event monitor GUI 
application's startup code may be implemented using the 

20 COApplet class. 

For determining the user's event monitor 
service options, the GUI client application requests 
and retrieves user profiles including the user 
entitlements from an event monitor customer database 

25 populated by a periodic feed (e.g., on a daily basis) 

from StarOE 39 (Figure 36) . 

From the event monitor GUI client 
application, an alarm management object is also 
launched upon initialization of the GUI client 

30 application. The alarm management object essentially 

creates a blank user interface and starts a thread to 
handle communications with the event monitor server for 
events or alarms . The alarm thread is created to run 
periodically, e.g., every two minutes. Specifically, 

35 the AlarmThread invokes a COAsynchronousTransaction 

with the web server to poll for current event monitor 
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alarms. When the AlarmThread receives the data back 
from the web server, it creates a command to update the 
display and executes the command. 

The event monitor alarms are generally 
5 grouped into two categories: voice alarms and data 

circuit alarms, including broadband and SNMP alarms. 
Voice alarms are further divided into two types: 
service outage alarms which are generated when a 
percentage of circuits in a trunk group are not 

10 available to complete calls; and traffic alarms which 

are generated when a percentage of DALs reach a 
predefined percentage for blockage, terminating failure 
rates and originating failure rates. Traffic alarms 
are based on data accumulated for five or thirty minute 

15 intervals. Data alarms are divided into two types: 

service affecting alarms which are generated in 
instances where the service cannot be used because 
there is a loss of Signal, unframed signal or equipment 
failure; and performance affecting alarms which are 

20 generated when high error rates are received for ten 

seconds or more, out -of -frame conditions occur or frame 
slips exist but service is still available. A Drill 
down view depicting each alarm down to the individual 
circuit is available via the GUI as will be described 

25 below. 

Reporting functionality 

As described above, the existing and new 
event monitor reports may be requested via the report 

30 requestor, a component of StarWRS. The reports are 

then posted in the inbox. Customers view the reports 
by launching the report viewer applet, another 
component of StarWRS. Once the report is made 
available, at the customer's preference and selection 

35 based on priorities and severity, the customers may 

receive notification through one or any combination of 
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page, e-mail, or fax in addition to the display option 
of the notification on the customer's inbox. For 
example, a customer may choose to receive page and 
e-mail notification on all level 1 severity alarms and 
just display notifications in the inbox for level 2 
severity alarms, etc. 

Recurring reports may also be created by the 
user to run on a timely basis, e.g., hourly, daily, 
weekly, and monthly, as well as ad hoc (one time) 
reports. For example, a customer may have a standard 
DAL performance report delivered on a daily basis, and 
on a particular day, the same customer may choose to an 
submit ad hoc DAL performance report for any given 
interval, i.e., previous hour, previous several hours 
or days. 

In addition, the event monitor may provide 
the ability to drill down within customer's premise 
equipment to view a breakdown of the customer's 
equipment and the ability to monitor performance and 
report alarms on individual channels within each 
circuit. Giving customers the capability to create and 
save a variety of reports and graphical views allows 
them to perform customized trending and analysis for 
maintaining better control and problem resolution 
schemes during their network management process. 

Moreover, the event monitor presents via the 
report viewer applet, the map of the continental U.S. 
(World for global customers/services) for purposes of 
displaying the configuration of a customer's network. 
The customer may view their sites, the various 
connections between any two or more of these sites, and 
information about each specific site and circuit. The 
topographical mapping display allows customers to see a 
logical depiction of their network. The ability to 
drill down into individual sites, nodes and circuits 
are also available via the viewer applet. For example, 
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if a customer has a circuit between New York and Los 
Angeles the highest level of the map shown may be the 
two locations on either end as well as the circuit 
between them. If a customer clicks on the circuit 
itself, raw data pertaining to the current throughput 
of that circuit or any alarm conditions that exist on 
the circuit may be displayed. Additionally, if the 
customer clicks on either of the two locations, further 
drill down for logical design layout of the customer 
premise equipment, such as a DSU or CSU, may be 
enabled. Furthermore, if alarms are present for that 
particular site, the drill down view may depict each 
alarm down to the individual circuit on a 24 channel T- 
1. 

Another type of reporting service provided by 
the event monitor is called an integrated management 
services bouncing busy intervals report. This report 
provides a picture of a DAL group during its busiest 
time of the day by reporting statistics for the current 
or one of the previous 7 days at the busiest interval. 
The busiest interval is defined to be the 30 -minute or 
60 -minute time period in which total usage was at the 
highest point. Other reports which may be obtained 
through the event monitor include: monitoring and 
performance reporting of individual DS3 and OC3 
circuits, IDSN channels, International voice or data 
point-to-point private lines, El lines; and trunk 
utilization reports. 

Alarming functionality 

The event monitor presents all detected 
alarms to the customer automatically, without the 
customer's intervention. The detected alarms within 
the event monitor are sent to the customers' inbox for 
spreadsheet display for on-line reviews. All current 
alarms are retrieved by the customer's web browser GUI 
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applet using polling techniques at session initiation. 
Customers may define a period of time during which 
their alarms remain in current status, allowing non- 
current alarms to be deleted. 

In addition to providing alarm notifications 
to customers, the event monitor may also provide a 
scheme in which a pre-defined trouble shooting 
procedure, modifiable by a customer, is launched 
automatically when an alarm is detected. For example, 
if an alarm is generated regarding a fiber outage that 
impacts a customer's toll free circuit, an option 
allows the user to go directly from the alarm message 
in the inbox to the appropriate alternate routing plan. 
In order to integrate two services, i.e., event monitor 
with toll free network manager (TFNM) , the event 
monitor key data and alarm are communicated to allow 
TFNM to find the appropriate routing plan associated 
with the outage. The key data may include: toll free 
number, service id, circuit id, and type of service, 
e.g., toll free or broadband. The TFNM application is 
typically launched directly from an alarm view with the 
above parameters for finding the associated routing 
plan. User profile information needed by TFNM for 
authentication and entitlement verification before 
actually proceeding with the alternate routing plan, 
are also passed as parameters to the TFNM application 
at the same time. 

Performance metrics 

The event monitor follows and conforms to 
general "networkMCI Interact" reporting standards in 
order to provide a consistent and common interface to 
the customers. Weekly reports do not have to be on a 
calendar week and may cover any consecutive 7 days. 
Monthly reports are, unlike the weekly reports, 
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calendar based and are defined to cover the entire 
month. Ad -hoc reports are reports outside the pre- 
selected reporting structure and are available to 
customers within two minutes from the point of request 
by customers. 

In a preferred embodiment, the event monitor 
alarms are distinguished into two types: event-based 
alarms, and statistical alarms. Event -based alarms are 
alarms generated on the physical connection between the 
customers CSU/DSU circuits and the telecommunication 
service provider's switches, e.g., alarms occurring due 
to a loss or bring -down of a circuit. In addition, the 
customer may specify this notification to be sent as a 
page, fax, or e-mail. In these cases, the notification 
is sent within the required 30 -second window from the 
moment the alarm is detected by the event monitor. 

Statistical alarms are alarms generated due 
to the percentage of down time or of other statistical 
nature. Statistical alarms depend on the frequency at 
which the customer's web browser is polled, e.g., 2-4 
minute intervals. Once polling is established and an 
alarm is detected, the time- to- deliver notification of 
the alarm is similar to the event-based alarms, i.e., 
within 30 seconds. 

The event monitor back-end configuration 

Figure 37 illustrates an example of a back- 
end configuration 1002 for the fault management system 
for reporting telecommunication service conditions. 
The back-end configuration includes a network 
management system 1004 which collects network events, 
including alarms and traffic densities from a common 
carrier network 1006. All of the events collected by 
network management system 1004 are reported to an event 
monitor host 1008. The common carrier keeps track of 
the performance and network faults for network 1006 
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through a myriad of network management systems 1004 and 
routes the information in real-time to the event 
monitor host 1008. In order to provide information 
regarding a particular customer's leased services, 
events collected by event monitor host 1008 are 
downloaded to event monitor server 1050. 

Event monitor server 1050 accumulates in near 
real-time a database of events pertinent to each 
customer's leased services. The accumulated data is 
viewable via the client browser application GUI and 
also via the StarWRS reporting system as described 
above. Because individual customers may subscribe to 
various different services which may experience 
different events, event monitor server 650 must not 
only collect different sets of data on a real-time 
basis, but the client browser application GUI and the 
reporting system must also present the data in a format 
relevant to the particular services to which the 
customer subscribes. This data may be organized for 
display to the user in an event queue. 

In the preferred embodiment of the present 
invention, event monitor host 1008 is an Integrated 
Network Management System (INMS) host implemented as an 
IBM S/370 mainframe and the event monitor server 1050 
is implemented as an IBM RS6000 computer; the 
architecture of this embodiment is depicted in Figure 
38. The present invention may be implemented in other 
ways, as would be apparent to one skilled in the 
relevant art. 

Referring to Figure 38, INMS host 1008 
operates in an .IBM Customer Information Control System 
(CICS) environment and includes an IBM virtual 
telecommunications access method/network control 
program (VTAM/NCP) interface 1012 for making an IBM 
System Network Architecture/Logical Unit interface 
version 6.2 (SNA LU6.2) connection to a mainframe 
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client gateway (MCG) 1014 of INMS host 1008. The MCG 
1014 in turn makes a Transport Control 
Protocol/Internet Protocol (TCP/IP) connection to IBM 
RS6000 event monitor server 1050, which operates under 
5 the IBM Advanced Interactive Executive (AIX) 3.2.5 

operating system. 

Server 1050 comprises two servers: a 
Structure Query Language (SQL) server 1016 and an open 
server 1018. Open server 1018 receives events from 

10 INMS host 1008 and stores them on a database 1010 

stored on server 1050. The SQL server 1016 is a 
database engine providing access to and managing 
database 1010. In the preferred embodiment, database 
1010 is a Sybase® database and SQL server 1016 is a 

15 Sybase® SQL server. 

Database 1010 compiles information that is 
sent on a regular basis by INMS host 1008. The data 
stored in the SQL server may be queried at will by a 
user via the client browser application for analysis. 

20 Database 1010 is a relational database using SQL server 

1016 as the database management system (DBMS) . In the 
preferred embodiment, database 1010 comprises two 
databases. The first database includes information 
relevant to other network management applications (for 

25 example, MCI Service View®) , such as facilities and 

circuit prefixes, and a customer mapping table for all 
customers subscribing to the event monitor service. 

The second database includes statistics 
relating to the various facilities monitored by network 

30 management system 1004. In the preferred embodiment, 

these statistics are compiled an updated on a regular 
basis, by MCI Extended Super Frame Monitoring Units. 

An additional database accessed and utilized 
by the fault management system is a customer database 

35 located with the StarOE server 1050. This database 

includes specific event information such as alarms, 
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reporting and user information. It also tracks the 
users who log on from the various client terminals via 
the client browser applications and stores such 
information as the user's log on password, access 
5 security, and the various alarm descriptions and their 

status as reported by network management system 1004. 

Database 1010 includes a number of tables of 
data which are accessed by the client browser 
application GUI to event displays, including alarm 

10 displays, alarm report, facilities cross-references and 

event log displiays. In addition to the StarOE 
authentication and entitlement checking, user access to 
database 1010 is monitored by SQL server 1016; levels 
of security may be provided to permit tiers of access 

15 to different levels of information within database 

1010, as would be apparent to one skilled in the 
relevant art. 

The data within database 1010 is organized in 
views. For example, an alarm view provides an alarm 

20 description, an alarm severity representing the degree 

of consequence for the alarm, and selected conditions 
associated with the alarm. 

The interface between INMS host 1008 and 
server 1050 is one-way, from the INMS host only. In 

25 - this scenario, the INMS host 1008 is a client, issuing 

calls for stored procedures to SQL server 1016 via MCG 
1014 when there is an event to report. 

When MCG 1014 receives a request from INMS 
host 1008, it accepts an LU6.2 conversation and creates 

30 a local area -networked- based connection to SQL server 

1016. The request is then forwarded to SQL server 
1016, which updates database 1010 with the information 
sent by INMS host 1008. 

Figure 39 is a high level logic flowchart 

35 depicting the operation of the preferred embodiment of 

the present invention. Typically, a customer 
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subscribes to several particular leased services. In 
order to limit data collection to data germane to those 
particular services, the user must specify the data to 
be collected. The user does this by defining an event 
view of data to be collected, as shown in a step 102 0. 
The event view specifies, for example, which services 
are to be monitored and what data is to be collected 
and reported for those services. For example, the 
event view may include the following items: 

Severity: critical, major, minor, 
informational, no alert. 

Service Types (MCI): 800, 900, TDS 1.5, TDS 
45, VNET, Prism®, Vision®, ISDN, SW56, and DDS/DDO. 

Corporate Identifiers: A list of corporate 
identifiers related to the customer's enterprise and 
for which the user is authorized access. 

Facilities: All elements of a physical 
telephone plant required to provide a service and to 
which the user is authorized access (for example, trunk 
groups and circuits) . 

Data Elements: The user can configure a 
customized event view by selecting the data fields to 
be displayed. 

Date and Time Elements: The user can 
configure a customized event view by selecting the date 
and time period for the custom event view. 

Sort Order: The user can configure a 
customized event view by selecting, for example, the 
data fields on which the data to be displayed is 
sorted. 

Once the event view has been defined, the 
client browser application transmits a transaction 
request to the server 1050 via the web/dispatch server. 
An SQL statement is generated at the server 1050 to 
create the event view from data stored in database 
1010. In the preferred embodiment, the SQL statement 
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is constructed such that each element/field is joined 
by an "AND" and values within each element/field are 
joined by an "OR." Thus, an example partial SQL 
statement may be depicted as follows: 

Severity = critical OR severity = major 

AND 

Service Type = VNET 
AND 

CORPID = 123434 OR CORPID = 32432423 
AND. . . etc. 

The SQL statement created in step 1023 is 
forwarded to SQL server 1016. The SQL statement 
identifies to SQL server 1016 the particular stored 
procedure to be activated to obtain the event view 
specified by the SQL statement. The SQL server 1016 
then executes the stored procedure and builds a report 
of event data specified by the event view, as shown in 
a step 1028. 

Once the event report is built, it is sent to 
the client browser 20 via the web/dispatcher servers. 
The events are typically loaded into an event queue. 
The events in the event queue are sorted by sort 
criteria entered by the user when defining the event 
view, as shown at step 1032. In a preferred 
embodiment, the primary sort criterium is severity. 
The sorted events are displayed to the user on the 
client browser Application GUI in a step 1034. Each 
event displayed is accompanied by an acknowledgment 
field for the user to indicate his acknowledgment of 
the event; for example, the user may acknowledge an 
event, if so authorized, by entering an asterisk in the 
associated acknowledgment field. When the user 
acknowledges an event, as indicated by the 11 Y 11 branch 
from step 1036, the client browser application reports 



-216- 



WO 99/15979 



PCT/US98/20I70 



the acknowledgment to server 1050, as shown at step 
1038. When the user has acknowledged the last event in 
the event queue, as indicated by the "Y" branch from 
step 1040, event processing ends. At this point, the 
user may either retain the session or close it. 

If the session remains open, server 1050 will 
report new events defined by the event view as they are 
received by server 1050. When server 1050 receives a 
new event, as indicated by the "Y" branch from step 
1042, processing resumes at step 1028, as shown in 
Figure 39. 

Thus, in accordance with the event view 
defined by the user and communicated to event monitor 
server 1050, reports of events identified in the event 
view may be continuously forwarded to the client 
browser application, and made available in an event 
queue for display to the user in order of the severity 
of the event. 

CALL MANAGER 

Another application of the suite of 
telecommunications network management applications is 
the call manager ("CM") system which provides 
sophisticated mechanisms, e.g., intelligent call 
routing, for call center customers to control delivery 
of toll free calls from the telecommunications 
enterprise network to call centers, including call 
centers having multiple Automatic Call Distributors 
(ACDs) . Particularly, using the CM system the 
customers have the ability to define routing rules 
which, on a call by call basis, determine the best 
place to route incoming toll free calls. A high level 
overview of the call manager system environment 1100 is 
illustrated in Figure 40. The call manager system 1100 
generally includes a service control point (SCP) 1110 
for providing call manager routing features, known as 
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"call by call" (CXC) routing; an intelligent routing 
customer element (ICE) (not shown) ; an intelligent 
routing host (IR host) 1112; and client workstations, 
i.e., call manager webstation client 1130, and/or Nexus 
workstation client 1126. The SCP 1110 is a routing 
engine which essentially maintains call routing rules 
and uses those rules to determine where to route the 
calls. A typical call processing flow for a call 
received from a caller 1122 includes routing requests 
and responses from the enterprise switches 1124 through 
above-mentioned data access points (DAPs) 616 and 
remote data gateways (RDGs) 1118 into and out of the 
SCP 1110. The DAP 616 executes a routing plan by 
translating a toll free number passed by the switch 
1124 into a network number, and maps it to an address. 
The RDG 1118 provides a standard gateway allowing 
communication between the SCP host 1110 and the 
enterprises backbone network. The translated network 
number is then communicated to the SCP host 1110 via 
the RDG 1118. 

Data collection and storage of ACD-based 
statistics from customer call centers and network 
statistics are supported by DAP traffic statistics 
(DTS) 1114, the IR host 1112 and the ICE components. 
The DTS collects network routing statistics from the 
DAP 29 06 and passes them to the IR host 1112. The IR 
host 1112 stores routing statistics from DTS 1114 and 
the ACD 1120. The ACD 1120 data statistics are 
collected by the ICE for each ACD 1120, normalized by 
the IR host 1112 and provided to the SCP 1110. When 
the SCP 1110 receives a routing request, the SCP 1110 
typically determines the best location to route a call 
by modeling each call center using periodic Automatic 
Call Distributor (ACD) 1120 data statistics to keep the 
model in line with what is actually going on at each 
location. 
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Upon completion of call processing according 
to customer routing plan, the DAP 2906 passes routing 
instructions to the switch 1124 for setting up the call 
to a customer's ACD 1120, The ACD 1120 balances the 
load of calls based upon customer defined rules such as 
the "busyness" of a call center. Calls may be 
distributed evenly using "round robin" technique, 
or directed in which calls are routed based on a 
percentage allotted to each destination identifier. 
Voice communications are carried from the switch 1124 
to the ACD 1120 which terminates the call at the 
appropriate trunk or destination identifier. 

The routing capabilities supported by SCP 
.1110 include a termination selection based upon one or 
more of the following: initial list of eligible 
destinations, destinations eliminated from 
consideration based upon tested conditions, 
artificially biased evaluation criteria, percent 
allocation, and manipulation of user-defined peg- 
counter variables. SCP 1110 also supports the routing 
and blocking of incoming calls using event -level data 
based on one or more of the following characteristics: 
day of the week, day of year, preference of destination 
choices, time of day, membership of the automatic 
number identification (AND or caller entered digits 
(CED) in a defined list of values, load balancing 
and/or availability at specific destinations, user- 
defined quota schemes, user- defined peg - counters , 
preference of destination choices, and artificial bias 
of load balancing algorithms. 

The Call Manager Integrated Data Server (s) 
(CMIDS) 1140 are included to provide a front -end 
functionality to the SCP host 1110 and off-load various 
workstation- related processing from the routing engine. 
In addition, the CMIDS 1140 may directly access data 
stored on the IR host or on other data servers. 
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Further details of the CMIDS 1140 will be described 
with reference to Figures 41 and 45. 

As shown in Figure 2, the call manager system 
of the nMCI Interact System further includes one or 
more web servers 1132 for providing browser -based 
customer connections from the World Wide Web (WWW or 
Web) . The call manager web server 1132 passes the 
customer connections through to the SCP host 1110 via 
the CMIDS 1140, and thus delivers the call manager 
functionality to the call manager webstation client 
1030 via a standard web browser and the Internet. The 
web server 24 is accessed by customers using the public 
Internet by directing a web browser 20 running on the 
call manager webstation to point to a call manager 
Uniform Resource Locator (URL) . 

The call manager webstation 1130 may be any 
hardware/ software platform connected to the public 
Internet and running a supported web browser. The call 
manager webstation 1120 is typically owned and 
maintained by the customer. The call manager 
webstation 1130 includes a web-based graphical user 
interface (GUI) application which enables the customers 
to define their call terminations, and provision 
routing rules and associated tabular data to control 
routing by the SCP host 1110. The GUI application also 
presents alarms and near real time graphical displays 
of peg counts and ACD-based statistics. The 
application also provides reports and data extracts of 
historical data, including call detail records (CDRs) , 
ACD-based statistic, and peg counts. In addition, 
user- id administration functions including business 
hierarchy structures and function profiles may be 
performed via the call manager webstation 1 s web-based 
GUI application. 

In addition, the Nexus client workstation 
1126 is included as an alternative client for the SCP 
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host 1110. The presence of the call manager webstation 
1130 does not preclude use of the Nexus client 
workstation 1126. The Nexus client workstation 1126 
typically runs a graphical user interface application 
for enabling the customer to define their call 
terminations, routing rules and to display the ACD and 
routing information in either tabular or graphical 
forms. The Nexus client workstation 1126 are directly 
connected to the SCP host 1110 typically via dedicated 
circuits to customer premise locations or through the 
enterprise backbone networks for the enterprise 
locations . 

Call Manager Webstation architecture 

Figure 41 illustrates call manager webstation 
component architecture showing interconnections among 
the components. In a preferred embodiment, the call 
manager webstation system includes three components of 
the call manager platform: client desktop systems, or a 
workstation, hereinafter referred also as the client 
webstations 1130 for delivering call manager functions 
through a standard web browser; a web server 1132 for 
supporting secure access for internet or 
extranet/intranet -based clients to call manager 
back-end and thus to SCP hosts; and call manager 
integrated data server (CMIDS) 1140, forming an 
integral part of the back-end call manager application 
and supporting access to SCP host systems. As shown in 
Figure 41, the client desktop systems 1130 with 
Internet connectivity have standard browsers executing 
Java applets, i.e., a client GUI application, 
downloaded from the call manager web server 1132. The 
web server 1132 which is located in the above -described 
demilitarized zone (DMZ) 17 of the network MCI Interact 
system, include Java class files, but no storage of 
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customer data to insure data security. The DMZ is 
generally bounded by two firewalls: an Internet 
firewall 25 (a) and an enterprise intranet firewall 
25(b). The call manager integrated data server (CMIDS) 
generally handles the business and data logic 
associated with the call manager functionality. Each 
of the above components will now be described in detail 
with reference to additional figures. 

As described above, the client webstation 
1130 provides a web-based graphical user interface 
(GUI) offering data management and data presentation 
features for the call manager system. The web -based 
front -end GUI is typically written using the Java 
programming language to insure platform independence. 
The client webstation 1130 typically includes a web 
browser with Java applets for the interface for 
providing access to the call manager webstation 
application from a standard web browser, e.g., Internet 
Explorer V4.01. In addition, the networkMCI Interact 
common objects are used for implementing many functions 
needed for client/server communications protocols. The 
Java applets generally reside on the web servers 1132 
and are dynamically downloaded to the client browsers 
(client webstations 1130 when the Uniform Resource 
Locator (URL) for the call manager webstation client 
GUI application is accessed. 

The call manager webstation client GUI 
application of the system of the present invention is 
typically invoked by clicking a "call manager" icon 97 
from the networkMCI Interact home page 79b (Figure 
5(b)). The customer is then presented with a toolbar 
for launching each of the call manager webstation 
application features as shown in Figure 49 at 11880. 
Moreover, on-line help is offered via hyper -text markup 
language (HTML) documents residing on the web servers 
1132. 
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Each call manager webstation application 
feature may be accessed through an icon button in a 
tool bar 11880 as shown in Figure 49. Moreover, each 
feature is brought up in a separate window frame, 
giving a consistent look and feel throughout the web 
environment. As shown in the example display of Figure 
49, the main features offered include: user setup and 
administration, i.e., security functions at 11882; 
business hierarchy setup; call by call application for 
rules writing and provisioning at 11874, 1884; graphic 
data display at 1878; alarm manager at 1872; and 
reporting and data extracts at 1876. A detailed 
description for each of feature will be provided with 
reference to Figure 48 below. 

For providing the above features, the client 
browser includes class objects making up the client 
interface code, in a first embodiment shown in Figure 
42. Specifically, the user interface classes 1134 
represent the main GUI objects for performing a call 
manager specific functionality. Each of the classes, 
i.e., user and business hierarchy setup, call by call 
application, graphic data display, alarm manager, 
reporting extracts, and authentication/entitlements, 
performs the corresponding client -side functionality 
associated with the call manager features provided. 
The web server classes 638 provide the communication 
pass through to the back-end server. The communication 
classes (not shown) are employed between the client 
browser 1130 and the web server 1132 for requesting 
transactions and/or data sets from the web server 1132. 

In the first embodiment, the communications 
from the client 20 and back-end CMIDS 1140 (Figure 41) 
via the web server 1132 are conducted using the common 
gateway interface (CGI) . Requests from the client are 
typically first targeted at a CGI program, which then 
relays the request to the appropriate proxy process. 



-223- 



WO 99/15979 



PCT/US98/20I70 



Results are returned from back-end processes to the 
requesting client in the same manner. Each transaction 
or data request may be executed as a separate process, 
to allow processing to continue from other applications 
within the call manager webstation system. 

In a preferred embodiment, a Netscape Server 
Application Program Interface (NSAPI) module may be 
used as an alternative to the CGI layer, the NSAPI 
module replacing the CGI -protocol communications layer 
between the client 20 and the web server 1132. The web 
server 1132 may be configured to pick up the NSAPI 
module and load on start up. Java client code 1134 
(Figure 42) may be configure to refer to the NSAPI 
module. For example, the Java client may invoke a 
method to communicate directly with the NSAPI module 
that performs the same function as the CGI program. 
Using the NSAPI module enhances performance and 
messaging throughput. When the server 1132 recognizes 
requests for the NSAPI module, it invokes a particular 
function in the module which performs essentially the 
same function as the CGI program. For example, a 
middle tier transaction handler, typically a message 
manager (msgmgr) and residing with the web servers 
1132, may be modified to use the NSAPI instead of the 
HTTP CGI. The advantage of NSAPI over CGI is that a 
new process need not be created whenever a request 
comes in from the web client 20. 

In general, and as described above, the web 
server 1132 provides a communication pass -through 
between the web client GUI application 1130 and the 
back-end call manager integrated data server (CMIDS) 
1140 which may communicate with the SCP host. Figure 
43 illustrates one embodiment of the software 
architecture showing communications between the client 
20 and the web server 1132 and its components. The web 
server 1132 provides web -based call manager 
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applications to web clients having a web browser on 
their client workstations 20. The web server 1132 
includes an HTTP service manager 1152 and a message 
manager 1156. The HTTP service manager 1152 generally 
handles requests from multiple clients 113 0 to download 
web pages and Java applets for display within a browser 
Web pages include hypertext markup language (HTML) 
files and Java applets 654 that are downloaded to the 
clients 20 and are executed within a browser by the 
Java applets. The HTTP service manager 1152 also 
handles message transactions via the POST method 
defined by the hyper- text transfer protocol (HTTP) 
protocol. The HTTP service manager may be standard 
off-the-shelf World Wide Web server software, e.g., 
Netscape Enterprise Server. 

The message manager 1156 is typically a CGI 
program that is executed as a spawned process within 
the HTTP service manager 1152 when a message 
transaction is received from the client via the POST 
method sent to the HTTPS port (443) 1150. The HTTP 
service manager 1152 spawns a process to run an 
instance of the message manager 1156 each time it 
receives a message transaction from the client. 
Alternatively, the message manager 1156 may be 
implemented as a function in the NSAPI module as 
described above. The HTTP service manager 1152 then 
invokes the message function in the NSAPI module. Both 
input and output streams are created by the message 
manager 1156 to receive message data from the client 20 
and to reply back to the client 20. The message 
manager 1156 is generally responsible for the 
following: 1) accepting new user login by allocating a 
new session key for a newly created session; 2) 
attaching a dispatcher and proxy header to the web 
client's message and forwarding the message to the 
proxy server 1170; and receiving a SCP host response 
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message from the proxy server 1170 and re-wrapping this 
message with dispatcher and proxy header and sending 
this formatted message to the web client 20. Message 
transactions are sent to the proxy server 1170 over a 
new connection by opening a new TCP socket to the proxy 
server 1170 while the original socket from the browser 
is blocking, waiting for a response from the web server 
1132. 

Typically, communications to and from the 
client 20 take place over hyper- text transfer protocol 
secure (HTTPS) , which uses hyper- text transfer protocol 
(HTTP) over a secure socket layer (SSL) encrypted 
channel. Applications may include web pages in the 
form of hyper- text markup language (HTML) files and 
Java applets 654 that are stored on the web server 
1132. The HTTP service manager 1152 downloads the HTML 
files and Java applets 654 to the client 113 0 upon 
request via the HTTPS port 1150, typically configured 
to port number 443. Each transaction from a client 20 
is sent to the web server 1132 in the form of a logical 
message that has been encrypted. The web server 1132 
decrypts the message and wraps the message with the 
user's information, including environment variables and 
a server -generated session identifier (id) . The 
message is then encrypted and forwarded to the CMID 
1140, or alternately, as will be described below, to 
the proxy server component of the CMID 1140. 

The message transactions created by the 
client 20 may be transmitted over HTTPS using the POST 
method defined within the HTTP protocol. Using the 
POST method, a specified CGI program and more 
specifically, an invoked message manager runs as a 
thread in the HTTP service manager 1152. Message data 
is passed to the message manager 1156 by opening an 
input stream and an output stream within the thread . 
As described previously, the HTTP service manager 1152 



-226- 



WO 99/15979 PCT7US98/20170 

spawns a message manager process 1156 for each message 
transaction sent to web server 1132. Each message 
transaction is a single request from the client 20 that 
is answered by a single reply from the web server 
1132. 

The web server 1132 also includes a session 
manager 1158 and a session table 25(a) for providing 
session management functions including the 
authentication of various web requests. A session is 
defined as the amount of time between which a client 20 
logs onto the web server 1132 and when the client logs 
off. During a session, a client 20 may submit many 
message transactions to the web server 1132. State 
data for each session is stored in the session table 
25(a). Session entries are deleted from the session 
table 25(a) when a user logs off or when a session is 
aged. Each message transaction received by the web 
server 1132 is associated with an active session. If a 
session no longer exists for a particular transaction, 
the message transaction is returned to the client 20 as 
rejected. The application then may prompt the user to 
login again. 

Generally, the session table 1160 is a table 
that has state information on all current client 
sessions that are active on the web server 1132. When 
a client logs onto the web server 1132 and is 
authenticated, the client is provided a "session id" 
which is a unique server -generated key. The client 
holds this and returns it to the server as part of 
subsequent message transaction. The session table 1160 
maintains a "session key table" which maps these keys 
to the associated session. The session table also 
includes a time stamp for each client session. A 
client session's time stamp is updated each time a 
message transaction containing the session id for the 
session is received. A session is aged if no message 
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transactions belonging to the session are seen after a 
given amount of time. If so, the session, with its 
entry deleted from the session table 1160, is logged 
off from the SCP host 1110. 

The session manager 1158 is generally 
responsible for monitoring all current client sessions. 
The session manager 1158 typically monitors the 
sessions by accessing the session table 1160 and 
checking the current time stamp values for each current 
session. If the time stamp value shows that a session 
has aged, the session entry for the aged session is 
cleared from the session table 1160. Clearing the 
session entry forces any further message transactions 
associated with the session identifier to be rejected, 
requiring the user to restart the session. 

For communications to and from the web client 
20 and the back-end, the middle- tier web server 1132 
supports three types of transport mechanism which are 
provided by the networkMCI Interact platform: 
synchronous, asynchronous, and bulk transfer, as 
described herein. Particularly, the Synchronous 
transaction type typically has a single TCP connection 
which is kept open until a full message reply has been 
retrieved. The Asynchronous transaction type is 
typically used for handling message transactions 
requiring a long delay in the back-end server response. 
A server process handling the message transaction 
responds back to the web client 20 immediately with a 
unique transaction identifier and then closes the 
connection. The web client 20 may then poll the web 
server 1132 using the transaction identifier to 
determine when the original message transaction has 
completed. The bulk transfer type of transport 
mechanism is typically used for large data transfers 
which may be virtually unlimited in size. 
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In the embodiment shown in Figure 43, the web 
server 1132 includes a proxy server 1170 and a database 
1172, e.g., Informix database. In this embodiment, the 
web server 1132 includes capability to communicate 
directly to the SCP host, bypassing the CMIDS 1140, by 
having the proxy server reside physically in the we 
server. 

Figure 44 illustrates an example of call 
manager webstation application physical architecture 
when one or more call manager web servers 1132 bypass 
the CMIDS component of the present invention. As 
shown, the call manager web servers 1132 directly 
communicate the MML messages, i.e., translated client 
requests, to the Nexus SCP host 1110. In addition, in 
this embodiment, it is the SCP host 1110 which receives 
ACD statistics, alarms and other information from the 
IR host 1112, and communicates the information to the 
web servers 1132. The SCP host 1110 serves as the 
routing engine through which customer provision routing 
rules, and associated tables or list, view alarms, route 
peg counts, etc. It houses the applications used by 
customers to manipulate the features of their automated 
call distributor (ACD) . Figure 44 also shows the call 
manager web client 2 0 as being authenticated via the 
networkMCI Interact platform and the StarOE 
authentication and entitlement system 29 as described 
herein, i.e., the networkMCI Interact platform 
validates the password and authenticates with the 
StarOE system 631, verifying that a customer's profile 
allows access to the call manager webstation 
application. Upon valid authentication, the call 
manager webstation application session may begin with 
the client webstation communicating with the call 
manager web servers 1132 for providing the various 
functionalities . 
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In another embodiment, the data processing 
components for business and data logic, i.e., the proxy 
server and the database, resides with the CMIDS 1140, 
thereby reducing the functions of the web server 1132 
5 to an application server providing primarily state and 

session management. Porting the proxy server 1170 over 
to the CMIDS 1140 may be easily performed. The 
transaction handler in the middle tier, i.e., the 
message manager 1156 still passes messages between the 

10 Web client 20 and the CMIDS 1140. The only change 

needed is that the transaction handler connects to the 
proxy residing on the CMIDS 1140, as opposed to the 
proxy 1170 on the web server 1132. 

The proxy server 1170 generally processes 

15 message transactions from the client 20 and is 

multithreaded to handle multiple message transactions 
simultaneously. The proxy server 1170 is designed to 
process one type of message transaction or a set of 
message transactions. In this embodiment, routing of 

20 the messages to and from the proxy is handled by the 

message manager 1156. The proxy server 1170 also 
interacts with a database 1172, e.g., Informix, to pass 
back information to be displayed by the client 20. The 
proxy server opens a connection to the SCP host 1110 to 

25 retrieve information about routing plans or report 

statistics by sending the SCP "man machine language" 
protocol (MML) commands. Upon retrieval, the proxy 
server 1170 formats a response message which is sent 
back to the client webstation 1130 so that it is 

30 displayed on the current web page. As the message 

reply is sent back to the client 20, each thread 
created by the proxy server 1170 is completed. It 
should be noted that the proxy server 1170 need not 
reside in the web servers 1132. Instead, as will be 

35 described with reference to Figure 45, the proxy server 

1170 may reside in the CMIDS 1140, the back-end 



-230- 



WO 99/15979 



PCT/US98/20170 



server component. 

The database 1172 generally maintains 
information needed to translate the messages to and 
from the SCP host 1110. A message translation program 
written in 4GL accesses the database 1172 when a 
message transaction is received . The program 
translates the message and sends the message to the SCP 
host 1110 for processing. After the message has been 
processed, the program translates the response and 
sends it back to the message manager 1156. The proxy 
server 1170 typically invokes an instance of the 
translation program for each message transaction it 
receives and processes. As noted above with reference 
to the proxy server, the database 1172 may also 
alternately reside in the CMIDS with the proxy server. 

In the first embodiment, a data server, i.e., 
the CMIDS, is included. In this embodiment, much of 
the functions of the proxy server are performed within 
the data server. More specifically, the proxy server 
1170 and the database 1172 may be ported over to the 
CMIDS 1140. The web server 1172 communicates to the 
proxy in the CMIDS 1140 which then communicates with 
the SCP host. The call manager integrated data server 
(CMIDS) 1140 generally services web requests for the 
webstation application and serves as a front -end for 
the SCP host 110. Referring back to Figure 41, the 
CMIDS 1140, in addition, provides data storage and 
management for data resident on the SCP host 1110, the 
IR host 1112, and/or other servers. The CMIDS 1140 
also provides pass through connectivity for rules 
writing and other provisioning from the client 
webstation 1130 to the SCP host 1110. The CMIDS 
includes databases 1142a -c and provides an interface 
1162 to the call manager SCP host 1110 for rules 
writing and list management. CMIDS databases 1142a-c 
are extracted or replicated from the SCP host 1110 
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and/or the IR host 1112. The SCP host 1110 services 
are typically requested and satisfied through a 
protocol known as "man machine language" (MML) 
commands. The CMIDS 1140 utilizes MML as well as other 
interface mechanisms supported by the SCP host 1110. 
The call manager integrated data server (CMIDS) 1140 
physically resides on hardware located behind the 
intranet firewall 25(b) as shown. 

The proxy server 1170 and the database 1172 
which were described with reference to the web server 
1132, may reside in the CMIDS 1140. In addition, the 
CMIDS 1140 may also include a session manager and 
associated session table for managing host sessions. 
As described above, the proxy server 1170 generally 
handles webstation client 20 requests passed from the 
web servers 1132 by accepting message transactions from 
the webstation client 20 via the web servers 1132, 
maintains logging information, sends the request 
to a session manager, and receives data from back-end 
and forwards to the web servers 1132. In addition the 
proxy server 1170 may accept messages originating from 
the Nexus client workstations (1126 at Figure 40) , and 
perform user logon validations for the Nexus client 
workstation 1126. The Nexus client transactions, with 
the exception of the user logons, are passed directly 
to the SCP host 1110 for processing via a Nexus port 
manager (not shown) . 

The session manager 1158, residing in the 
CMIDS 1140, receives data from the proxy server 1170. 
The session manager 1158 updates the sessions table 
1160, validates that the user has proper privilege to 
perform the task and determines whether the transaction 
originated from a webstation 113 0 or a Nexus client 
1126. The user validation function may be performed for 
the webstation client 20 also, in addition to a 
validation conducted by the networkMCI Interact StarOE 
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authentication and entitlement system during the 
session logon. 

CMIDS 1140 also may include a Nexus host 
formatter, a CMIDS transaction manager, and a Nexus 
5 port manager. The session manager 1158 typically 

passes a transaction request received from the web 
server 1132 to either the Nexus host formatter, or the - 
CMID transaction manager. The Nexus host formatter 
module services transactions requiring SCP host 

10 services to fulfill the reguest. If the transaction 

originated from a Nexus client workstation 1126, the 
MML command message is adjusted to use a selected 
generic id for access to the SCP host 1110. If the 
transaction originated from a webstation client 20, the 

15 request is translated to the correct MML format. When 

the message is prepared, it is then sent to the Nexus 
host port manager component. 

The CMIDS transaction manager module services 
transactions that do not require the SCP host 1110, 

20 i.e., the types of client request which may be serviced 

locally on CMIDS, including: obtaining NEMS alarm 
information, obtaining GDD information, and processing 
of user security. When the local processing is 
complete, results are sent back to the proxy server 

25 1170 component. 

The Nexus port manager component of the CMIDS 
manages pools of session with one or more SCP hosts 
1110. The Nexus port manager logs onto each session in 
a pool using a "generic" user id. Using a "generic" 

30 user id enables each session to access an individual 

user's data without having to log each user onto the 
SCP host 1110. MML commands for a particular user are 
sent to a SCP host using any available session in the 
pool of "generic" session. After an MML command is 

35 sent and a response is received, the session is 

returned to the session pool and freed for use by the 
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succeeding transactions. A session pool is defined as 
a set of sessions connected to one particular SCP host 
1110. Therefore, the Nexus port manager component of 
CMIDS 1140 supports multiple session pools for 
communicating with multiple SCP hosts 1110. 

The Nexus port manager also maintains state 
of each session in each pool. The Nexus port manager 
generates a keep-alive-message whenever a session is 
idle to keep the SCP host 1110 connection from being 
dropped. If a session in a pool has failed, the Nexus 
port manager will try to reestablish the session and 
add it back into the pool when establishment is 
completed. The Nexus port manager determines the 
communication channel to use to access the SCP host 
1110 and keeps a number of connections open to the host 
1110. Each message is sent to the SCP host 1110 and 
the channel blocked until a response is received. 

Figure 4 5 is an example of a CMIDS conceptual 
model 1140 providing details of the CMIDS software 
components. The components perform specific 
functionalities of the back-end which will also be 
described with reference to Figure 46. The CMIDS 
software architecture includes proxy 1148, proxy, 
system administration, and inbox components applicable 
to the call manager webstation (CMWS) application. 

The CMWS proxy 1148 is generally a logical 
internal software entity which verifies application 
access and interfaces with host application. Depending 
on the application access chosen by the customer, 
either the networkMCI Interact dispatcher or the CMWS 
web server 1132 communicates client transactions to the 
CMWS Proxv 1148. The networkMCI Interact, as described 
herein, typically accepts the encrypted customer 
request from the networkMCI Interact web server 
cluster, and it interfaces with a CMWS proxy. The user 
account interface software component 1143 generally 
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maintains sessions with the SCP hosts and provides the 
functions of the Nexus port manager described above. 
The report handler process generally maintains 
databases 1142a -c and provides reporting facilities, 
5 The CMIDS back-end interface 1191 supports a number of 

interface mechanisms including MML and command line 
access to the Nexus SCP host, common alarm and logging 
services, and data retrieval from the IR host. 



10 The call manager webstation back-end 

As described generally above, the back-end is 
responsible for transmitting web client request to the 
SCP host and delivering the host reply information back 
to the web clients. For supporting the request/reply 

15 transmissions, the back-end system of the present 

invention generally includes three logical components: 
front -end interface (BFI) , translate/data manager 
(TDM), and back-end to Nexus, i.e., SCP host interface 
(BNI) . It should be noted that SCP host functionality 

20 is currently implemented on the Nexus, hence the 

acronym BNI. However, other host systems are not 
precluded as having capability to support the SCP host 
functionality for the purposes of the call manager 
webstation system of the present invention. 

25 Figure 46 illustrates a back-end process flow 

1200 for the system of the present invention. A 
customer 1122 typically dials a toll-free number. As 
an illustrative example, this toll-free number may be 
provided by a company having operators taking telephone 

30 orders. In addition, the company provides three trunk 

lines or destination identifiers going into its ACD. 
The company services a call centered media -based sales 
application, e.g., home shopping network through this 
ACD which includes a toll-free number for customers to 

35 call. To handle calls to the home shopping network 

client, the company sets up an ACD path group called 
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"HSN" . This ACD path group includes the three trunk 
lines as member destinations and reports agent and call 
statistics from the total number of agents servicing 
home shopping network, regardless of the particular 
5 trunk lines. 

Accordingly, as shown at step 1241, when the 
customer 1122 dials the toll-free number, the call goes 
to the network through the switch. At step 1242, the 
call is passed from the switch to the DAP for 

10 translation. The DAP translates the toll-free number 

to a network number and maps it to an address readable 
by the RDG . NetCap 290 generally houses routing plans, 
destination labels, toll-free numbers, logical 
terminations, DAP-based details and trigger plans 

15 required for the call manager webstation system. Most 

of this data may be provisioned in NetCap 290 via the 
Toll Free Network Manager (TFNM) application service, 
as described herein. Seeing the trigger point and 
other DAP-based data provisioned from NetCap 290, the 

20 DAP passes the call to the RDG at step 1243. At step 

1244, call statistics are saved in DAP traffic 
statistics (DTS) for use in case of time-out or other 
failures. They are also stored within the IR host. 
At step 1245, the RDG, with its ability to communicate 

25 with the SCP host, passes the network number and 

associated address to the call -by- call (CxC) routing 
application on the SCP host. Based on instructions in 
the rule set defined by the call manager webstation 
system customer, the CxC application selects the HSN 

30 ACD path group at step 1246. At step 1247, CxC 

application then selects the individual destination 
identifier within the ACD path based on the specified 
distribution method which may be either even/ "round 
robin" or directed/percentage distribution. At step 

35 1248, the call is routed back through the RDG to the 

DAP. Then at step 1249, the DAP routes the call to the 
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ACD via the specified destination id or trunk. 
Specifically, referring back to the above illustrated, 
example, calls receive on Thursdays between 5:00 and 
7:00 GMT may be set to be routed to Orlando, and 
accordingly the destination id is Orlando Central. The 
CxC routing application returns destination id "Orlando 
Central" to the network, which routes the call to the 
ACD via the Orlando Central destination id or trunk. 

Call manager client GUI application implementation 

As in the other nMCI Internet network 
management client applications, the call manager client 
application (CMApp) is preferably derived from the 
(common object) COApp class and may be launched by a 
backplane object that is typically derived from the 
COBackPlane class, including the networkMCI Interact 
backplane (Figure 3) . 

In one embodiment of the present invention, 
the call manager client application is launched in a 
separate browser window from the one within which the 
networkMCI Interact backplane is' running. For example, 
after validating that a customer's profile allows 
access to the call manager application, and after a 
customer clicks the call manager icon 97 on the 
networkMCI Interact home page (Figure 5(b)), the 
networkMCI Interact backplane creates a separate 
browser window and populates the call manager 
webstation URL. The call manager webstation web server 
then downloads the call manager client application for 
execution within the new browser window. The call 
manager client application downloaded from the server 
includes a CMBackPlane class which is an applet derived 
and inherits from the COBackPlane class . The 
CMBackPlane is launched with the call manager 
webstation web paqe and provides backplane 
functionalities within the context of the call manager 
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webstation application. The call manager client 
application also includes a Feature class from which 
the CMFeature is derived. The CMFeature typically is 
invoked by the CMApp and provides an application 
specific functionality within the call manager 
application such as reporting, alarm management (NEM) , 
graphical data display (GDD) , and call by call 
application (CxC) . 

Upon the call manager application launch and 
initialization, the main toolbar sets its icon. For 
example, the browser starts the backplane applet which 
launches the CMApp by calling its init method. The 
CMApp calls set Icon method for setting up an icon for 
the main toolbar. The main toolbar may be implemented 
using a view of a model in a MVC paradigm described 
above. When a user presses a button on the main 
toolbar to launch a feature, e.g., NEMS, Rules, 
Provisioning, etc., the CMApp View derived from the 
theMainToolbar class creates/activates the selected 
feature and initializes it. When the CMFeature is 
instantiated or started, it invokes a setlcon method to 
create a frame, the CMFeatureFrame, in which to run the 
selected feature. 

Call manager webstation client application features 

As described above, the call manager 
webstation application allows authorized customers to 
manage their ACD data networks via a web -based 
interface. Specifically, customers are enabled to 
provision hierarchies for their business; control all 
routing of their toll-free traffic; create, modify or 
delete agent pools; manipulate capacity tables; and 
define quota schemes, value lists and schedule tables. 

In the manner as described herein, a customer 
at a client webstation 20 having Internet connectivity 
and a web browser, and after logon, is presented with 
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the networkMCI Interact home page [Figure 5 (b) ] 
downloaded from the web server. With downloading and 
presenting of the home page, the web browser at the 
webstation 20, deploys a backplane applet via which the 
call manager GUI client application is invoked. The 
backplane requests a list of authorized applications 
from the StarOE authentication and entitlement system 
for the networkMCI Interact platform and a select list 
of applications which may include the call manager 
webstation application, is enabled on the home page 
according to the customer specific entitlements. The 
call manager webstation application is then accessed 
from the home page [Figure 5 (b) ] . 

The customer may be presented with a call 
manager webstation application logon dialog box, in 
which the customer enters the call manager webstation 
logon name and password. In addition, the customer may 
be presented with a change password dialog. This 
dialog implements a password expiration design feature, 
which due to security reasons, the customer must change 
after a predetermined period of time. In addition, 
multiple hosts may be handled through the web client 
front -end and translation processing at the back-end. 
The front -end client application sends the "get- nexus - 
host" command to retrieve a list of SCP host names . 
The host information is stored at the back-end with the 
Informix database and, typically an SQL routine 
retrieves the available Nexus SCP host machines. The 
proxy residing at the back-end returns a list of the 
available Nexus SCP host machines to the front -end web 
GUI client application. The proxy generally maintains 
a "hosts" list having SCP host names and their IP 
addresses. Maintaining the list of host names on the 
proxy allows for easy modification of host names and IP 
addresses with no impact to the client code. 
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When the front -end web GUI client application 
receives the list, a list of host names may be 
displayed in a drop -down list for the customer to 
select, or the customer may be prompted for the Nexus 
SCP host machine desired. The selected host name is 
sent along with a login transaction having user 
name/password to the back-end, when the customer clicks 
a "login" button from the login dialog. The 
"establish- session" command is then sent to the 
back-end where the proxy may open a connection to that 
host. The proxy maps the SCP host name to the 
appropriate IP address and forwards the user login 
request to the host. The SCP host id selected at login 
is populated in the toolbar (Figure 48 at 1880) at the 
client webstation. 

An application- level process flow 1250 for 
the CMWS system is now presented in view of Figure 47. 
After an entered login name is validated by StarOE and 
user entitlements ascertained, the call manager 
webstation applet is downloaded to the customer 
webstation 1130, and as indicated at step 1254, the 
customer is presented with the screen 1870 shown in 
Figure 48 through which the customer may perform the 
call manager features of the present invention 
provided. These features include: manipulating user 
and business hierarchy by querying, creating, or 
editing user id records as shown at steps 1256 and 
1258; managing routing schemes via the call by call 
application as shown at steps 1260 and 1262a-k; 
invoking alarm manager at step 1264 and 1266 to view 
problems occurring across the call manager components, 
such as loss of connectivity, failure of ACD data 
collection, system failures, and application 
abnormalities; reporting and data extracts at steps 
1268, 1270 for printing, displaying and managing ACD 
statistics, alarm history, database usage, peg counter, 
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and system performance; and graphic data display at 
steps 1272, 1274 for viewing histograms and charts of 
ACD and peg-count statistics. 

More specifically, by selecting the option at 
5 step 1256, to manage a user and business hierarchy, 

via, e.g., the security button 1882 (Figure 48) from 
the toolbar 1880 (Figure 48) , a customer may search for 
a user id and, with appropriate privileges, create or 
edit a user id for a business level below their own. 
10 Through this option the customer may also access 

reporting visibility to all data items belonging to the 
customer and any business level below their own. In 
addition, the customer may assign a read, read/write, 
or no access privileges to each function in the user id 

15 profile. Moreover, the customers may administer and 

modify limits on the number of entities that a business 
unit may own in the provisioning database. 

By selecting the call by call application at 
step 1260, for example, by clicking on an icon labeled 

20 "Provisioning" (Figure 48 at 1874) on the call manager 

web station tool bar displayed on the screen 1870 in 
Figure 48, the customer may perform business hierarchy 
provisioning as shown at step 1262a. The customer may 
select the option at step 1262b and perform load- 

25 balancing by determining the degree of "busy-ness" by 

tracking the average call handling time, the number of 
agents, and the number of calls routed to each 
destination. At steps 1262c and 1262e, the customer is 
enabled to provision capacity tables for providing a 

30 default staffing allocation for use by the load 

balancing algorithm. With the CxC option and shown at 
step 1261d, the customer may also provision basic 
destination ids representing a single call termination 
on the network which may be a single telephone 

35 instrument or a line termination into a PBX. 

Destination ids with ACD feeds, which may represent a 
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single call termination into an ACD, may also be 
provisioned. Provisioning of ACD path groups 
representing a set of destination ids that terminate on 
the same physical ACD and share the same statistical 
data feed is also enabled. Provisioning of Destination 
Groups representing a set of logically related 
destination ids and/or ACD path groups is possible via 
the CxC option. Destination Groups are a convenience 
mechanism for writing rules that refer to multiple 
destinations without having to list each destination 
separately. In addition, the customer may provision 
distribution methods, e.g., even, which is a round- 
robin selection of destination ids or directed, in 
which the calls are routed to destination ids based on 
a percentage allotted to each destination id. 

At step 1262f, quota customers to specify and 
maintain call routing quotas for destinations. At step 
1262g, the customer is enabled to provision called 
numbers. For example, the customer creates a rule set 
associated with the called number. The rule set 
typically determines the location of the caller and 
selects the appropriate destination number for the 
nearest warehouse. At step 1262h, the customer may 
provision value lists which are sets of related numeric 
values. They are typically used in rule sets to test 
the attributes of an incoming call to determine a 
characteristic of the call or caller. An attribute of 
the call (such as the ANI) is tested against a value 
list. If the value of the call attribute matches an 
entry in the value list, then other rules are executed 
based on this logical condition. This feature is 
highly useful for non- English- speaking callers. At 
step 1262i, the customer may provision translation 
tables. The translation tabes include a highly 
flexible mechanism for performing a table lookup and 
returning a value that corresponds with the search 
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argument. At steps 1262 j and 1262k, the customers may 
maintain user variables such as setting up names for 
peg counters and rule variables and routing 
instructions . 

By selecting the alarm manager option at step 
1264, for example, by clicking on an icon labeled 
"NEMS" (Figure 48 at 1872) on the call manager web 
station tool bar displayed on the screen 1870 in Figure 
48, the customer may display various alarms for 
problems occurring across the call manager components. 
These components were described above. Typically, 
alarming is performed through the BMC patrol software 
agents with monitoring provided by the system 
operational support (505) organization, which monitors 
other components of the call manager platform. 
Patrol's "logwatch.cinf ig" allows setting up a file 
name and a selection string. Patrol agents typically 
monitor the file and pass alarms matching the selection 
string to the web clients. For logging application 
level alarms, a UNIX syslog facility is used. A set of 
"send- alarm functions" interfaced between the 
application processes and syslog daemon is added to a 
common utility library. Through the sendalarm function 
the call manager application processes send the alarm 
messages to the same log file with different levels of 
severity. The alarms with high level of severity is 
generally monitored by system operational support (SOS) 
organization through BMC patrol software. Each alarm 
message typically includes a process name, an alarm 
number, and a severity level. A typical alarm message 
looks like: "Apr 8 17:23:31 cmjwstest Process Name 
[Process PID] : [L0G_Alert Number] can't set up a 
connection to XXX Nexus at Line 65 File proxy." The 
alert number then may be used to determine possible 
solutions . 
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Referring back to Figure 47, selecting the 
reporting and data extracts option at step 1268, for 
example, by clicking on an icon labeled "Reporting" 
(Figure 48 at 1876) on the call manager web station 
tool bar displayed on the screen 187 in Figure 48, 
enables the customer to obtain reports of ACD 
statistics, alarm history, database usage, CDR 
extracts, Peg counters, and system performance. Each 
of these reports may be generated on-line or by a print 
function within the application. The ACD statistics 
are monitored in live, hear - real - time by the SCP Host 
application. A load -balancing algorithm uses ACD 
statistics to determine the "busy-ness" of a 
destination. When an ACD Path Group is selected as the 
least busy location by the load-balancing algorithm, 
one of the individual destination ids within that ACD 
path group is picked to carry the call. The reports of 
alarm history permit the customer to view the status of 
alarms and events on the various hosts. An alarm or 
event may be an informational message sent autonomously 
from a host. Database usage reports generally provide 
information on users, typically by user id, accessing a 
workstation, SCP host, or CxC application. CDR 
extracts generally provide a database record of call 
detail record information about a called number 
translation query and its outcome of the routing 
translation process. Peg counters generally represent 
a series of accumulators that are available to the user 
for counting actions or situations encountered in a 
rule set. System performance reports allow the 
customer at a workstation (webstation) to monitor 
capacity of the host and application components to 
foresee and prevent possible outages. 

Selecting the graphic data display option at 
step 1272, for example, by clicking on an icon labeled 
"GDD" (Figure 48 at 1878) on the call manager web 
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station tool bar displayed on the screen 1870, enables 
the customer to obtain and view histogram, chart, and 
line graph displays of ACD-based statistics and routing 
peg counts, which may be refreshed as frequently as 
once per minute. 

Rules writing, testing, debugging application features 

The rules feature (Figure 48 at 1884) allows 
users to write rules for routing of toll free calls. 
Rules may load balance based on call center capacity 
and route based on automatic number identification 
(AND, caller entered digits (CED) , or quotas. Via 
this feature, users may also test, install, uninstall, 
and swap rules as shown at Figure 48. The bottom half 
of screen 1870 in Figure 48 displays a typical rules 
writing/editing template . The users may build 'rules on 
the rules construction area 1882 by including 
statements selected from the constructs list box and 
the statements list box 1884. The users may also 
select various options 1886 available for the selected 
construct or statement for building the rule. 

For enabling a rule writer to test a rule 
set, the rules feature provides a rules debugger/ tester 
functionality which runs a rule set against a set of 
test data, i.e., call context, simulating call 
scenarios in which to test a rule set logic. This 
optional facility allows rule writers to check if their 
rule set exhibits the expected behavior, for example, 
before installing the rule set on the network. 
Moreover, because this test feature is purely optional, 
a rule writer need not run the rule testing 
functionality before the rule is installed. 

When a customer, e.g., a rule writer, selects 
the debugger/ tester feature option, a rules testing 
dialog appears. Via this dialog, a user may define a 
call context parameters for simulating call scenarios 



-245- 



PCT/US98/20I70 



in which to test a rule set logic. The basic call 
context includes called-number, ANI , CED, carrier, date 
and time of the call. Optionally, the user may also 
modify the different parameters of destinations and 
quotas that may affect the load balancing. 

In addition, an option to allow the database 
to be updated during the simulation is also provided. 
During the testing process, the customer may step 
through the simulation one line at a time or choose a 
"Run" command to run through the entire call all at 
once. Furthermore, during the simulation, the customer 
may select from various view tabs to view, including, a 
log view, a destination status view, a destination 
details view, a CDR view and a user variable view. 

For executing the testing process, the 
debugger/tester uses the MML interface to Nexus, i.e., 
the debugger/ tester formulates the user actions to one 
or more MML commands and sends the translated command 
to the SCP host. The SCP host typically stores the 
state of testing (including the different views of the 
log), and manages the test execution. 

System status display 

Typically, a system status display 1850 shown 
in Figure 49, is opened by selecting "System Status 
Display" from the security button on the main toolbar 
(Figure 48 at 1882) . The dialog is non -modal having a 
top half having a dialog 1852 including general 
information about the system, and, a bottom half 
including a combination box 1854 that allows the user 
to select between the different options described 
above, i.e.: application status, ACD gateway status, 
partner links status, signaling network links status, 
and webstation session links status. Selecting an 
option displays a list including information relevant 
to that option. As shown at 1854, selection the 
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application status displays information including 
application names 1856 , instance numbers 1858, desired 
states 970, actual states 1862, release numbers 1864 
and TPS 1866. Similarly, selecting the ACD gateway 
status option displays information including gateway 
names, gateway states, gateway link states, collector 
link states, and dates/times of last change. Selecting 
the partner links status option displays host names, 
states, link states, sync states information. Likewise 
the signaling network links status option displays 
information which includes linkset names, link names, 
states, dates/times of last change, and adjacent point 
codes. Selecting the WebStation session links status 
option displays information such as workstation 
instance numbers, locations, states, user ids, and 
dates/times of last change. 

When a message prompting user readiness is 
received by the host, the host sends system status 
messages on a regular interval. The length of the 
interval may vary anywhere from every second to every 
minute. The system status display messages are 
automatically sent from the SCP host, once the messages 
are turned on. The backend typically stores this type 
of message received from the SCP host until the client 
queries for it. A unique set of data is stored for 
each user currently performing a system status display. 
Subsequent messages received from the SCP host 
typically overwrite previous data. 

The host administration functions 

A user may select to perform host 
administrations by selecting the appropriate icon from 
the main tool bar (Figure 48). In response, a pull- 
down menu from is presented with options including: a 
backup option for backing up server database to a user- 
selectable back-up medium, e.g., tape or a disk; an ACD 
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gateway administration option for providing users with 
the ability to view, create, delete and edit ACD 
gateways; an ACD collector administration option for 
providing the user with the ability to view, create, 
delete and edit ACD collectors; a FMS gateway 
administration option for providing the ability to 
view, create, delete and edit FMS gateways; and FMS 
collector administration for providing the ability to 
view, create, delete and edit FMS collectors. 

When the ACD collector administration option 
is selected, a dialog 1870 shown in Figure 50 opens 
with a list of retrieved gateway types. Typically the 
client GUI application sends two messages to 'retrieve 
information needed to populate the dialog box 1870. A 
"rtrv-acd- type" is used to fill the gateway type combo 
box 1872. A "rtrv-acd- status" is sent to retrieve 
information 1874 on the selected gateway type. 
Clicking a row in the list 1874 of enables the delete 
button. Typing characters into the site collector name 
1878 enables the Add button 1879. The FMS 
administration dialogs share the same dialog box with 
the above described ACD gateway and collector 
administration functionalities. The same messages, 
i.e., the "rtrv-acd- type" , and the "rtrv-acd- status" , 
are sent to the back-end but with different parameter 
types, e.g., "FSM" or "ACD." 

Company branding 

The CMWS component of the nMCI Interact 
system supports a branding functionality which allows 
users to open the call manager webstation application 
in a company specific context. The CMBackPlane class 
is derived from the COBackPlane class, which is an 
applet, which inherits all of the applet attributes and 
methods. This branding feature may be equally used in 
the other applications of the present invention when 
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the BackPlane class for that application is defined. 
The main URL for the branded application uses 
JavaScript, a client side scripting language, to render 
the html. The JavaScript, typically, directs the 
browser to retrieve a company brand. The browser then 
opens the application web page with the company web 
page specified in the query portion of the URL. 
Typically the appliction applet retrieves a company 
brand name by invoking a get Parameter method (an applet 
method) , and sets the brand name in the application 
specific globals class by invoking a setBrand method. 
This feature of the present invention enables resellers 
of enterprise telecommunication services to brand those 
services and features as their own when providing them 
to a third party user or customer. This facilitates 
the adoption and resale of unused enterprise capacity 
through a reseller market. 

Language support 

The CMWS component of the nMCI Interact 
system additionally provides an internationalization 
feature, supporting local languages for text displays. 
This optional feature allows a user to open the call 
manager application in a language as set by the user. 
Subsequent texts and phrases are rendered in the 
language chosen. Typically, the call manager 
webstation application is opened with a default 
language as set by the operating system. The user is 
also given an option to select a language other than 
the default. A call manager applet typically 
determines the . local set for the operating system and 
launches the appropriate language version by including 
the locale as a parameter. For example, the parameter 
with a name "locale" may have one of the following 
values: "en_US n for English US, "en_CA ,f for English- 
Canada, and M fr_CA ,f for French Canada. The applet uses 
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this value to set the locale for the system string and 
phrase resources. A CMResource class handles the 
general resources of character encoding, numeric 
formatting and date formatting. 

5 

Online invoicing 

Another application of the suite of 
telecommunications network management applications is 
an online invoicing system, herein referred to as 
10 "ClientView, " which provides customers with the ability 

to view invoices and reports online, and offers a 
facility for printing and faxing documents. The online 
invoicing system takes information available from 
different billing systems and incorporates that 
15 information into its database for subsequent retrieval 

and presentation to a user according to user- specif ied 
requests. A general block diagram illustrating the 
online invoicing system architecture 1300, integrated 
with the networkMCI Interact platform, is shown in 

20 Figure 51. Generally, as shown in Figure 51, the 

ClientView system 1300 is integrated within the nMCI 
Interact system comprising: the user web browser 1320 
which employs a ClientView GUI 1330 for providing an 
interface to which a customer may request and view 

25 various billing invoices associated with the 

application services subscribed by the customer and 
provided by the networkMCI Interact system via a secure 
socket connection for presentation invoice reports. 
For example, using the GUI client application 20, 

30 customers may drill down on their applicable invoices, 

typically accessing them via the given customer 
identifiers such as the corp id, bill payer, or mega 
account numbers. The invoice reports may also be 
available for various application services including 

35 toll free, Frame Relay, and ATM; StarWRS client- side 

report viewer and requestor processes 2 00 which 
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provides the support for generating and presenting 
reports relating to the conditions of the customer's 
dedicated voice and data networks as described herein; 
a corresponding server side reporting component having 
the above described inbox, report scheduler and report 
manager components, in addition to alarm and report 
viewer and requestor components implementing Java 
applets having viewer classes that enable the 
downloading and display of reports generated from 
ClientView server processes 1350. 

Also shown as part of the online invoicing 
invoice viewing system architecture 1300 of Figure 51 
is the Web server/dispatcher component 1335 which 
provides for the transport between the Web browser and 
an online invoicing proxy interface 134 0 including all 
secure communications and encryption. Thus, customer 
requests and server responses may be communicated from 
the user browser 1320 to the online invoicing server 
1350 in a secure manner. Specifically, the dispatcher 
1335 forwards user requests, such as "get index" 
message for retrieving a list of documents available 
for viewing by a customer, to the online invoicing 
server 1350 process that employs an integrated proxy 
application 1340 for receiving and interpreting the 
user messages and performing the online invoicing 
functionality. This proxy capability includes a 
multithreaded engine enabling multiple, simultaneously 
executing sessions supporting anticipated user load. 
The interface between the dispatcher server 1335 and 
the online invoicing server 1350 is also message-based, 
employing e.g., TCP/IP socket transport, and, as will 
be desribed, a messaging protocol that is defined and 
which includes a generic message header followed by 
proxy- specif ic data. The same process of messaging 
scheme is employed in the other direction. That is, 
the online invoicing proxy 1340 sends the generic 
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header, followed by the proxy- specific response back to 
the dispatch server 1335 for communications over the 
firewall and back to the user browser 20. 

The online invoicing proxy 1340 uses the 
networkMCI Interact platform 1 s "template proxy" as an 
implementation of the listener/slave portion of the 
proxy. The proxy 1340 passively listens on a 
previously defined port number and forks a process on 
an interrupt basis, after which the parent proxy 
continues to listen for other request. The forked 
process is generally dedicated to handling the detected 
requests. The forked process detects a transaction 
type from the proxy protocol header. The transaction 
types generally include synchronous, asynchronous, and 
bulk transfer, as described above. The proxy 134 0 then 
calls a "back-end" function whose function is dependent 
on the transaction type detected. The back-end 
functions typically provide individual services for 
which the application is responsible. 

For example, if the transaction type for a 
detected request is of "synch" type, the forked process 
executes the synch back-end function and passes the 
request as an argument. The synch back-end function 
generally passes the request to a CICS task on the 
online invoicing server and waits for a response. More 
specifically, the synch function first establishes a 
CICS task via a direct TCP/IP socket connection to the 
CICS TCP/IP interface service. The synch function then 
waits for a response indicating whether a connection 
was successfully established or an error occurred. If 
an error is occurred, an error response from the CICS 
task is returned to the synch function, which then 
terminates appropriately. 

If a connection to the CICS task is 
successfully established, the request is sent to the 
task and the synch function waits on a response. The 
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response is generally preceded with a preamble block, 
indicating the status of request and the number of 
bytes to follow. The preamble block may include an 
error code, indicating error conditions that may have 
occurred during the CICS task processing. Certain 
error indications may prompt the synch function to 
terminate the CICS task connection, and also to exit 
the synch function. 

If the preamble block indicates that the 
request was successfully processed, the preamble block 
is returned, and the byte count specified in the 
preamble block is piped from the CICS task, to the 
requesting process, and typically all the way back to 
the client GUI application. Upon completion of piping 
the data, the synch function disconnects the CICS task 
and exits. The forked process which called the synch 
function also terminates itself by exiting. 

In the preferred embodiment, the online 
invoicing server 1350 stores documents from various 
billing systems and performs the various database 
queries and function calls in response to requests 
received from the customer via the online invoicing 
proxy 1340. Particularly, the online invoicing server 
1350 is responsible for tasks including data 
collection, calculation, storage, and report 
generation. A more detailed description of the server 
1350 is provided with reference to Figures 55 and 56. 

During its operation, the online invoicing 
server 1350 supports communications with the StarOE 
server 39 which provides for authentication of users, 
supplying of entitlement information, and enabling 
order entry for the various online invoicing invoice 
viewing services order entry functions including 
functionality necessary to manage (create update, 
delete) online invoicing users, and feed the 
appropriate order entry information to the online 
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invoicing server 1350 in order to properly associate 
the appropriate online invoicing functionality and data 
to the right customer once given admission to the 
online invoicing invoice viewing service. 

As described previously/ order entry for the 
networkMCI Interact browser and all applications on 
networkMCI may be made through the networkMCI StarOE 
order entry system. The online invoicing application 
service may be ordered for all business markets 
customers. For example, a user may select to have 
online invoicing invoices for a given enterprise, corp, 
bill payer, and/or mega account number. These include 
all NCBS, Toll Free, PLBS, and Mega invoices. In 
addition, selections may include invoice images for 
MCI CVNS-ROW, MCI CVNS -Mexico, MCI CVNS -Canada as well 
as Stentor Advantage Vnet/CVNS invoice images. 

In the preferred embodiment, a messaging 
interface is utilized between the StarOE 39 and the 
online invoicing server 1350 for communications means. 
The online invoicing server 1350, typically functions 
as a client and receives authentication information, 
billing ids, and level of service information, which 
may also be supplied in response to the launch of the 
online invoicing GUI client application 1330. For 
example, when online invoicing client application 1330 
is launched from the home page [Figure (b) ] , a customer 
identifier such as the userid and the applicable corp 
ids and mega account numbers may be retrieved by the 
order entry system administration server, StarOE 39, 
and passed to the online invoicing server. The online 
invoicing server then makes the necessary association 
to individual bill payers that the user is authorized 
to view. The view of invoices may include a particular 
portion of the invoice as well as the entire invoice. 

The online invoicing server 1350 also may 
interact with the StarWRS inbox server 270 by storing 
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the news information regarding the online invoicing 
service, in addition to the event notifications, and 
report data from the networkMCI Interact application 
services . 

In addition, the invoice files saved on the 
inbox may be retrieved and viewed using the report 
requestor 21 and the report viewer 215 components of 
StarWRS 200 (Figure 10) residing in the user browser 
20. Via the report requestor, the customer may request 
tailored reports regarding the invoice files and view 
or print the customized invoice reports displayed by 
the report viewer as described herein. 

An application- level process flow 1360 for 
the ClientView system is now presented in view of 
Figure 52. After successful logon and entitlement 
determination (by StarOE server) , and upon selection of 
the online invoice (ClientView) application from the 
downloaded networkMCI Interact homepage to the user 
[Figure 5(b)], a ClientView applet is invoked at step 
1362 to display an online invoice screen at the 
customer workstation. As indicated at step 1364, the 
user then enters the customer identifiers on the online 
invoice screen which are then checked against the 
available list of customer identifiers in the online 
invoice server's database at step 1368. If the 
customer identifier does not exist or is not a valid 
type at step 1370, the user is prompted to re-enter 
the identifier at step 1365. Then the customer 
identifier is properly validated, the user is presented 
with the online invoicing products associated with the 
customer identifier at step 1372. The user then may 
select products by their date ranges at step 1374 for 
viewing. At step 1376, a server module then retrieves 
a list of document based on the selected product and 
date range from the online invoicing database, and at 
step 1378, the list is presented to the user, from 
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which the user may select to view a document, at step 
1380. Upon the user selection, the server modules 
retrieve the document from the database at step 1382. 
At step 1384, the invoice and/or report documents are 
presented to the user at the user's workstation. At 
step 1836 , the user may scroll through, or print the 
data presented, or the user may, at step 1388 select to 
view another document at step 1378. 

The information stored in the database 1355 
generally originate from different billing systems. 
When data is available from these billing systems, the 
online invoicing server typically performs a conversion 
process and stores the converted data on tape until an 
audit approval. When the converted data is audited and 
approved, the data having the invoicing documents are 
stored to the database 1355. After the data has been 
stored in the database for a predetermined period, it 
may be moved from a direct access storage device (DASD) 
and stored on optical platters. These platters may 
remain in an optical jukebox for another predetermined 
period and then migrated to an optical shelf where the 
data may be available for a certain period. 

Having described generally, an overview of 
the online invoicing application service and its 
integration with the networkMCI Interacts network and 
data infrastructure, the specific functionalities of 
the online invoicing application, namely the online 
invoicing GUI application on the client platform side 
and the online invoicing server in the enterprise 
Intranet, will now be described in detail below. 

Online invoicing GUI application 

As in the other nMCI Internet network 
management client applications, the online invoicing 
client application is implemented in Java to ensure 
platform independence and particularly is developed in 
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accordance with many of the networkMCI Interact' s 
common objects, as described herein, for achieving 
interoperability with the application backplane. The 
client component of the online invoicing includes a 
client interface for the user to select what data to 
retrieve. The data is then retrieved through various 
application processing, and a list of invoices and 
reports are provided for the user to choose from for 
online viewing. When a customer clicks on the "online 
invoice" icon 99 on the home page [Figure 5(b)], after 
a proper authentication via a logon, the customer is 
presented with a criteria screen 1900 as shown in 
Figure 53 (a) from which the customer may specify 
various types of, and date ranges for, invoices 
desired, e.g., Vnet invoices and the Concert Cross 
Border Reporting. The criteria screen 1900 is divided 
into a customer identifier section 1902, products 
section 1910, and dates section 1912. The customer 
identifier type includes identification by corporate id 
1906, account id, bill payer id, and/or mega id. Each 
online invoicing user is given at least one identifier 
type 1906 and a customer identifier number 1908 
associated with the type at the time of order 
entry via the StarOE. The StarOE maintains this 
customer information and communicates the information 
to the online invoicing GUI application, when the 
application is invoked by the backplane applet. 
Accordingly, at the same time the online invoicing GUI 
application displays the criteria screen 1900, it also 
populates the identifier type 1906 and customer 
identifier 1908 fields automatically as received from 
the StarOE user authentication and entitlement system. 

The user may then select a desired identifier 
type from the list of identifier types shown at 1906. 
The online invoicing GUI application then automatically 
fills in the customer identifier field 1908 associated 
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with the identifier type selected. In addition, if the 
customer's last selection was made with a certain type, 
e.g., corp id, the next time the customer views type 
criteria screen 1900, the corp id identifier type will 
be selected automatically. After selecting a desired 
identifier, the user typically then may execute the 
search of invoices available for that identifier by 
clicking on the retrieve button 19 04, pressing an enter 
key, or using a fast key combination such as Alt+S. 

The products and dates sections 1910, 1912 
are used for displaying the service products for which 
invoice viewing is available for a given customer 
identifier type and the date range for the available 
invoices. When the user executes the search, the 
products field 1910 is filled in with the date ranges 
1912, indicating available invoice reports for various 
period ranges. For retrieving invoice documents, the 
user may select ranges of dates including multiple 
ranges of dates as shown, and then click on the 
retrieve button 1904, press enter, use the fast key 
combination Alt+R, or click on any area within the date 
range list box 1912. 

Upon executing the retrieve user command, the 
online invoicing GUI application displays the screen 
1915 shown at Figure 53(b) listing the report 
documents. For each document, date, invoice number, 
bill player id, and number of pages are displayed as 
shown in screen display 1915. The status bar 1917 at 
the bottom of the screen may display a number of 
indices (document lists) loaded. The number of indices 
which may be loaded at one time may be configurable by 
a customer via the online invoicing GUI application. 
An invoice report listed then may be selected and 
retrieved by clicking on the retrieve button 1904, 
pressing an enter key or double clicking on a 
highlighted item 1918, or using a fast key combination 
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such as alt+R. When a selection is entered, a page 
range selection box 1920 appears. The selection box 
1920 allows customers to enter in the desired page 
range for viewing. The mail /payment option 1922 for 
retrieving only the remittance pages without having to 
retrieve additional invoice pages, is available from 
this screen. 

Figure 54 illustrates a sample invoice 
document 1925 retrieved when an invoice item is 
selected from a screen 1915 shown at Figure 53(b). 
Using the menu bar 1927 or a tool bar 1928, a customer 
may access the following functions: open a saved 
document; save the current document; print the current 
document; fax the current document; Batch Print a 
document; Search the document for word(s); display the 
first downloaded page; display the previous page; 
display the next page; display the last downloaded 
page; go to a specified page; increase the font size of 
the displayed document; reset the font of the displayed 
document to the default; decrease the font size of the 
displayed document; and, return to the screen that 
invoked the document. 

With more particularity, the batch print 
option may allow customers to send a batch print job to 
be performed at the enterprise Intranet to the 
customers, e.g., via Federal Express, at a location 
specified by the customer. 

Another feature provided by the ClientView 
system 1300 includes an accumulator function which 
allows customers to add up numerical figures, such as 
minutes and charges, by highlighting the numbers 
directly on the screen. 

The above-mentioned fax current document 
option offered by the online invoicing application 
includes an ability to fax to the customer, at a 
customer specified location, a current page, specified 
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range of pages, or the entire document by making an 
appropriate selection in a fax dialog box. 

Online invoicing server 

As described above, the online invoicing 
provides on-line visibility to various networkMCI 
Interact documents. In presenting various documents 
online to a customer, the GUI client application 
communicates to a online invoicing server via the proxy 
for retrieving up-to-date information which the server 
maintains. These documents are indexed and stored in 
the online invoicing 1 s database 1355 (Figure 52). The 
online invoicing server includes several processes for 
performing the indexing and storing of the documents. 

Figure 55 illustrates a process flow 1400 of 
the online invoicing server 1350. The server may 
receive data from a number of data centers 1432. 
Figure 56 shows three data center locations: location 
"A" 1432a, location »B M 1432b, and location "C" 1432c, 
as illustrative examples. At each site, invoice data 
associated with various products is available from 
various billings systems associated with the products, 
as shown at 1434. The products may include Vnet, toll 
free, Cross Border, Mega, etc. 

In a preferred embodiment, an online 
invoicing f s conversion process 1436 is used to convert 
documents at each of the data centers. The conversion 
process generally defines the key information necessary 
to retrieve the document and compresses the document 
for storing. Each conversion process 1436 generally 
performs the same tasks. More specifically, these 
tasks include creating a formatted compressed data set 
(FCDS) file and a conversion stats report for each 
conversion run. The FCDS file is the document which 
may eventually be incorporated into the online 
invoicing database. At step 1438, the online invoicing 
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conversion process reads in a PARM file and an invoice 
file. The PARM file includes document information such 
as the logical record length. The invoice file is read 
one line at a time and at step 1440, key information 
including page numbers and document dates is placed in 
a header record which is kept in memory until the FCDS 
file is created. At step 1446, the conversion process 
creates compressed pages of the document. The 
compressed pages follow the header record in the FCDS 
file. Once the FCDS file is created at step 1448, the 
file is stored on tape at step 1450, and the B and C 
locations NDM the tape to A at step 1452. At step 
1452, the conversion stats report is also created which 
includes page information and conversion information 
associated with each conversion run. The last line of 
the report has the conversion stats record, which 
includes the number of pages converted and the number 
of headers created. This report is then NDM'd to A by 
B 1432b and C 1432c and kept on DASD for future reviews 
and audit verification. 

The FCDS file is generally placed on hold, as 
indicated at step 1454, until audit approval is 
received through MCIMail, which is sent by various 
groups responsible for auditing and approving the 
document files sent to the online invoicing. Once the 
audit approval e-mail is received, an online invoicing 
production manually enters the product /division date 
and the invoice count into the audit statistics 
database 1459, at step 1456. The store job is manually 
released at step 1458 by the online invoicing 
production control after audit approval is received. 

The online invoicing includes a DB2 database 
subsystem residing in a NOR4 mainframe. The subsystem 
further includes an object database and an index 
database. An online invoicing store process 1460 loads 
the compressed document to an online invoicing object 
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database and an online invoicing index load process 
1480 stores index pointers to each document in the 
index database. An audit check is executed to ensure 
that the correct number of documents are added to the 
online invoicing databases during the object load and 
index load processes. 

More particularly, the store process loads 
the conversion stats record into the audit stats 
database at step 1462. At step 1464, the conversion 
records are then matched against the manually entered 
audit stats records. The store process 1460 also 
includes loading of the FCDS file from which is builds 
an index for each object and an index file, which 
includes the pointers to the document, as shown at step 

1466. The store process 1460, the loads the compressed 
documents into the online invoicing object database 

1467, as indicated at step 1468. At step 1470, the 
store process 1460 then creates a store status report 
and loads the report into the audit stats database 
1459. At step 1472, an audit checkpoint verifies that 
the stored numbers match the converted numbers. If 
there are nay errors with the numbers in the audit 
stats database at any point in this process, the job 
may automatically stop the store process 1460 until the 
feed/problem is corrected. Once these numbers are 
verified, the index process 1480 may begin. 

The index process 1480 at step 1482, i.e., 
EDINDEXX as shown in Figure 55 as an example, generally 
loads the index pointer for each document, which are 
typically created by the store process 1460. At step 
1484, the process 1480 also updates the account product 
table with new customer identifiers such as the corp 
ids or billpayers. At step 1486, the index process 
1480 creates an index status report. At step 1488, 
another audit checkpoint verifies that the index 
numbers match the stored numbers.. The stored and 
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indexed data are kept on DASD 1491 for a predetermined 
number of days, e.g., 45 days as shown at step 1492. 
After the predetermined number of days, the object 
access method (OAM) copies the files from DASD 1491 to 
an optical disk via the optical drive 1493. After 
another redetermined period, OAM migrates the objects 
from the optical disk to the optical shelf as shown at 
step 1494, where they remain available for another 
predetermined period of time. Once the indexes are 
loaded into the database, the documents are available 
for viewing. 

The following database tables are included in 
the online invoicing database: a product cross 
reference table which assigns the online invoicing 
product code to the product name; a CDSPARM table which 
keeps the store precess run statistics to allow for a 
restart when necessary and which includes an entry for 
each product code and runstream; an EDBAAPPL table 
which assigns a product code to a store group; a 
statistics audit table which keeps audit statistics for 
each product/runstream logged by the store process; and 
a conversion program parameter file which defines where 
the conversion may find the documents key information. 

The information on documents for imaging and 
storing are typically received from the various 
networkMCI Interact 's application services. 

The online invoicing server application is 
typically written in COBOL II using CICS/DB2 and OAM. 
The persons skilled in the art would appreciate that 
the server application may also be implemented with any 
other compiler languages or software tools. The server 
application includes a startup transaction (EDUP) , and 
a multipurpose transaction, EDS2 . The EDUP transaction 
passes several DB2 tables such as a function table, a 
version control table, and the batch print request 
table. The EDUP transaction also calls OAM to verify 
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OAM is active and to get the token for future calls to 
0AM. An in-core table is built for system information 
and temp storage records are built for version control 
and batch print pricing. The EDUP is generally 
executed at CICS startup time. 

EDS2 is. a multi-purpose transaction which is 
started when a request is received from a client GUI 
application. Its functions may include product and 
date listing, index retrieval such as shown at 1915 
Figure 53(b), and batch print request storing. The 
transaction uses the common top-level function 
(ED0CS000) and links to a lower level function designed 
to perform a specific task, based on a specific 
function. The lower level function results are passed 
back to the top-level function which checks return 
codes for possible error. The data result is then 
passed to the client GUI application via the proxy and 
the Web/dispatcher 1335 (Figure 51), and statistics are 
written to a VSAM file. EDS 2 is also executed for 
document retrieval for retrieving invoice documents 
shown at 1925 Figure 54. It uses the common top-level 
function and links to lower level functions to perform 
the retrieval processing. 

Figure 56 is a detailed ClientView server 
process flow diagram 2000 illustrating the server 
processes for responding to the client requests. After 
a user 2002 properly logs on the networkMCI Interact 
and invokes the online invoicing application at step 
2004, by selecting an appropriate icon on the 
networkMCI Interact homepage, the online invoicing 
client GUI application, at step 2006, generally 
requests communications with a listener process running 
in the server. 

Generally, the communications from the online 
invoicing server to the client workstation is performed 
by a set of calls to the TCP/IP address space. As an 
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example, a listener process, EZACIC02 is activated at 
CICS initiation, and constantly "listens" for 
activities. When a request is received from the 
client, the listener, e.g., EZACIC02, invokes the EDS2 
transaction, at step 2008. At step 2010, CICS invokes 
the first program, i.e., EDOCSOOO in the example shown, 
in the transaction EDS2 via the CICS transaction 
control table. Then, at step 2012, EDOCSOOO loads 
stem tables into memory. In addition, EDOCSOOO also 
makes calls to TCP/IP to communicate with the client 
GUI application. EDOCSOOO is also responsible for 
logging both successful and unsuccessful requests, as 
well as routing the request to one of many sub- 
programs, based on a function code and an object name. 
The sub-programs include EDOCS030, EDOCS001, 
EDOCS020/EDOCS040, and EDOCS220/EDOCS440 , each of which 
will be described in more detail below. 

When the listener process has a data to pass 
to EDOCSOOO, EDOCSOOO invokes a RETRIEVE command to get 
the data. EDOCSOOO then performs a take socket and 
responds to the client by a write socket. The client 
then typically responds to the server with a function 
code and additional data such as a customer identifier, 
dates, etc. EDOCSOOO performs data validation such as 
function codes, checks to see if the system is up, 
supplies pricing information for batch print, links to 
lower level functions, checks the results of the lower 
level results, produces error entries where needed, 
writes statistics, and passes any data retrieved (or an 
error) back to the client GUI application. 

After each call to a subroutine, EDOCSOOO 
checks a return code. EDOCSOOO also checks return 
codes from calls to the TCP/IP and posts an error 
message when the TCP/IP return code is a non-zero 
value, indicating an error. The errors are generally 
logged in the TCP data file and may be reviewed as 
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needed. When all the processing necessary for 
responding to the client is complete and response data 
is successfully sent to the client, the client GUI 
application sends an acknowledgment for the receipt of 
the data, back to the server. The socket is then 
closed, freeing it for another request to be 
communicated. 

Referring back to Figure 57 at step 2014, 
EDOCS030 is executed when a request is made to retrieve 
all products and dates associated with a customer 
identifier. This process gets all entries from the 
account/product cross-reference table for the customer 
identifier received from the client GUI application. 
For each entry in the account/product cross-reference 
table found, the process looks up the product on the 
product cross-reference table. If the group is 
different than any group processed yet, then the 
process adds an additional entry at the group level, 
gets the product description from the product cross- 
reference, and gets distinct dates for addition to the 
table. When the entries in the table have been 
exhausted, the process sorts the products, e.g., in an 
alphabetical order by product description followed by 
dates sorted in descending order, for proper display at 
the client workstation. At step 2016, the sorted data 
is returned to the client GUI application for viewing 
by the user. 

EDOCSOOO links to EDOCS001 and executes it 
when a client GUI application requests index retrieval 
for specified dates within specified products. 
EDOCSOOO passes in the customer identifier, the product 
and a list of dates received from the client GUI 
application as entered in the criteria screen 1900 at 
Figure 53(a). At step 2018, EDOCS0001 reads the index 
table and extracts from the online invoicing database 
all matching entries and sorts them in order of date 
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and invoice numbers. Different sorting, order may be 
utilized for different products. The entries meeting 
the product/date criteria are then sent back to the 
client GUI application for presentation to a customer 
at step 2020. The matching entry message, which is 
sent to the client GUI application includes a subset of 
entry records found. 

EDOCSOOO links to EDOCSO20/EDOCS040 and 
executes either one when a client GUI application 
requests for document retrieval such as the invoice 
document 1925 shown at Figure 54. EDOCS020 and 
EDOCS040 are generally used for document retrieval and 
are clones of each other. The difference between the 
two is that EDOCS020 was written for new style objects 
and EDOCS04 0 was written to handle old style objects. 
In their operation, EDOCS020 and EDOCS04 generally 
allocate storage for the document and retrieve the 
document meeting the requested page range into the 
allocated storage as shown at step 2022. The 
retrieved document is then sent back to the client GUI 
application for presentation to the customer. 

At step 2024, EDOCS220 and EDOCS440 are used 
for object searches on the document requested. These 
processes perform similar functions as do the EDOCS020 
and EDOCS040 processes. They typically get the 
collection name and the object, and loop through the 
index portion of the object to find pages in the 
requested range for the requested document. At step 
2026, the retrieved document is sent back to the client 
GUI application and is displayed on the user's 
workstation. 

For servicing batch -printing requests, 
EDOCSOOO may link to EDOCS050 and execute it. A next 
available request number is determined by getting the 
EDBPREQ record in the database and adding one to the 
last request number. EDBPREQ record is then updated. 
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The information passed to EDOCS050 is then mapped into 
the EDBPRINT table layout, and a new row is inserted 
into DB2. Errors from EDOCS050 are sent to EDOCSOOO, 
which reports them to the client GUI application. 

E-piUAflq 

On-Line E-Billing is an electronic commerce 
enabling tool that will allow selected networkMCI 
Interact customers to receive, analyze, and pay their 
invoice (s) over the public Internet. On-Line E-Billing 
provides a variety of Internet -based billing features 
that includes electronic invoice presentment, invoice 
analysis and electronic bill payment, all from a single 
point of customer authentication. 

By utililizing the present invention, 
customers may download their invoice information into 
their Accounts Payable systems. For the customer this 
will same time and money by not having to manually load 
the data from the paper invoices. In addition, this 
will increasing accuracy of the bill payment process 
for the customer. The present invention provides an 
"intelligent, navigable invoice" where customers and 
users can drill down from summuary level information to 
specific site and service level detail. By providing 
more timely receipt of information, the customer is 
able to identify inefficient and costly operations 
sooner, is able to make adjustments sooner, and may 
thereby save money that would otherwise be lost. 
Customers are also able to more easily analyze their 
invoices, thereby facilitating customer identification 
of inefficient/costly operations. 

The present invention utilizes Electronic 
Funds Transfer (EDF) , which provides for timely 
payment, reduces the "float" of funds and saves on 
clerical, postage and bank expenses. The Electronic 
Bill Presentment and Payment (EBPP) application and 
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database may reside on a highly secure "Virtual Vault" 
server technology that allows absolutely no remote 
access to the server. 

The On-Line E-Billinq portion of the present 
invention is initiated through the StarOE order entry 
system in a manner similar to that previously described 
with opening and modifying customer or user 
entitlements to the present invention. Each phase of 
the account setup, activation and confirmation is 
tracked and available for viewing by help desk/customer 
service personnel to aid in trouble resolution. .A Log 
is kept of errors for trouble/maintenance procedures, 
when registering for On-Line E-Billing the introductory 
web-page for registration is downloaded in a manner 
similar to the network MCI Home page previously 
discussed. This page tells the registrant what will be 
required to complete registration, including any MCI 
Corp and Bill Payer Ids, Taxpayer Ids, or other 
information that is not immediately accessible so that 
the customer can gather this information prior to 
initiating the process. 

During registration, the customer picks the 
the appropriate customer service segment for the 
customer. Once the segment is determined, appropriate 
customer service information is displayed to that 
customer. A "Click and Connect" 800 number for 
connection to networkMCI On-Line E-Billing 
applications support group is provided ("I need help 
with this application"). If a customer does not have a 
multimedia pc, the click-n-connect button is not 
displayed, only the 800 # for the application support 
group will be displayed. 

The customer or user then receives a screen 
notification that all data has been successfully 
received, and a confirmation number is noted on the 
screen notification. This confirmation number, (order 
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number) , is used to track the order. If the registrant 
did not enter the correct data needed for a successful 
registration, a screen notification will state the 
field that causing the rejection. 

Once the order is successfully received, both 
the enterprise account management team and the newly 
registered customer receive an e-mail confirmation that 
the order was received. As discussed previously with 
respect to Order Entry modification of customer 
entitlements, the notification includes customer id, 
names, level of access (view/ approve /pay) for each user 
and corp/billpayers they have access to, the user or 
customer registrant, and the registrants vnet, if 
applicable. Need to validate name, address, SSC, 
customer segment and corp id is also validated with the 
host COPS system. 

Preferably, the customer has the option of 
signing up for only one payment option at a time. The 
customer may be required to give a 15 day notice to 
change that payment option. 

The present invention also provides for a 
"print and pay" option wherein the customer may receive 
the invoice electronically, print it at the customer 
site, and render payment in a conventional manner. 
When the print and pay option is selected, the 
following fields are displayed to ensure the print and 
pay remittance slips are correct: 

- Invoice numbers 

- Invoice dates 

- Billpayer ID (s) 

- Invoice amount due 

• Customer name and number 

- Payment amount 

- Check number 
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A desired lockbox address for the enterprise 
may also be printed on the remittance page to ensure 
direction of the payment to the appropriate facility. 
If a customer signs up for EFT during registration, the 
customer's routing number is validated to verify that 
it is a valid routing number. After all EFT 
registrations, a "prenote" verification is provided 
that the customer's checking and bank account 
information is valid. The Electronic Fund Transfer 
feature utilizes ACH files for fund transfers through 
an appropriate banking institution. The ACH file is 
formatted as EDI 820 and must be encrypted. The 
following elements need to be included in the bank ACH 
file: 
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The customer receives a confirmation number 
for all EFT transaction. The customer has an option to 
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schedule recurring and non-recurring EFT options, 
including payment of non-recurring payments. The 
customer also has the ability to cancel a scheduled 
non-recurring payment if it is cancelled before X (TBD) 

of scheduled patent. When a non-recurring 

payment is submitted by the customer, an appropriate 
screen notifies the customer that the payment was 
accepted and is in pending status. 

Communications Security 

Communications security, which relates to the 
authenticity of the enterprise web servers 24 (Figure 
2) and the security of the transmitted data is now 
described with respect to an implementation in the 
preferred embodiment of the invention of the Secure 
Sockets Layer (SSL) version of HTTPS. 

In order for a communication to be secure, it 
must be known that the message comes from the correct 
source, that it arrives at the correct destination, 
that it has not been modified, and has not been 
intercepted and understood by a third party. Normal 
encryption protects against understanding .the message, 
even if intercepted, and certain types of cipher 
encryption provide the ability to determine that the 
message has been tampered with and in some cases 
reconstruct the message even if intercepted and 
intentionally garbled. The disadvantage of normal 
encryption is the difficulty associated with the secure 
distribution and updates of the keys used for 
encryption and decryption. 

Public key encryption solves the distribution 
and update problem, but does not, for the public 
Internet, ensure the identity of the party with whom 
one is communicating. A spoof er who appropriates the 
DNS address of an enterprise for a leg of the Internet 
can substitute the spoofers public key for the public 
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key of the enterprise with whom the user is attempting 
to communicate, thereby fooling the user into revealing 
the user name and password used on the enterprise 
system. To avoid this problem, digital signatures have 
been developed to ensure the identity of the sender. 
They also, simultaneously, commit the sender to the 
message, avoiding subsequent repudiation. 

The communications link between the 
enterprise and the user may be secured with S-HTTP, 
HTTPS, or proprietary encryption methodologies, such as 
VNP or PPTP tunneling, but in the preferred embodiment 
utilizes the Secure Sockets Layer (SSL) protocol 
developed by Netscape Communications. It is noted that 
these solutions are intended for use with IPv4, and 
that Ipv6, presently under comment by the Internet 
Engineering Steering Group, may enable secure 
transmissions between client and server without resort 
to proprietary protocols. The remaining security 
protocols of the present invention may be used with 
Ipv6 when it becomes an available standard for secure 
IP communications. 

The SSL component of the HTTPS also includes 
non- repudiation techniques to guarantee that a message 
originating from a source is the actual identified 
sender. One technique employed to, combat repudiation 
includes use of an audit trail with electronically 
signed one-way message digests included with each 
transaction. This technique employs SSL public -key 
cryptography with one-way hashing functions. 

Another communications issue involving the 
secure communications link, is the trust associated 
with allowing the download of the Java common objects 
used in the present invention, as discussed earlier 
with respect to the browser, since the Java objects 
used require that the user authorize disk and I/O 
access by the Java object. 
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Digital Certificates, such as those developed 
by Verisign, Inc. entitled Verisign Digital IDTM 
provide a means to simultaneously verify 'the server to 
the user, and to verify the source of the Java object 
to be downloaded as a trusted source as will 
hereinafter be described in greater detail. 

The above-mentioned authentication and 
encryption processes are performed in the handshake 
protocol, which can be summarized as follows: The 
client sends a client hello message to which the server 
must respond with a server hello message, or else a 
fatal error will occur and the connection will fail. 
The client hello and server hello are used to establish 
security enhancement capabilities between client and 
server. The client hello and server hello establish 
the following attributes: Protocol Version, Session ID, 
Cipher Suite, and Compression Method. Additionally, 
two random values are generated and exchanged: 
ClientHello. random and ServerHello . random. 

Following the hello messages, the server will 
send its digital certificate. Alternately, a server 
key exchange message may be sent, if it is reguired 
(e.g. if their server has no certificate, or if its 
certificate is for signing only) . Once the server is 
authenticated, it may optionally request a certificate 
from the client, if that is appropriate to the cipher 
suite selected. 

The server will then send the server hello 
done message, indicating that the hello -message phase 
of the handshake is complete. The server will then 
wait for a client response. If the server has sent a 
certificate request Message, the client must send 
either the certificate message or a no certificate 
alert. The client key exchange message is now sent, 
and the content of that message will depend on the 
public key algorithm selected between the client hello 
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and the server hello. If the client has sent a 
certificate with signing ability, a digitally- signed 
certificate verify message is sent to explicitly verify 
the certificate. 



is sent by the client, and the client copies the 
pending Cipher Spec into the current Cipher Spec. The 
client then immediately sends the finished message 
under the new algorithms, keys, and secrets. In 
response, the server will send its own change cipher 
spec message, transfer the pending to the current 
Cipher Spec, and send its finished message under the 
new Cipher Spec. At this point, the handshake is 
complete and the client and server may begin to 
exchange user layer data. 

Client Server 
ClientHello > 



At this point, a change cipher spec message 



ServerHello 



Certificate* 



S erver KeyExchange * 
Cert if icateRequest* 



< 



ServerHelloDone 



Certificate* 



C 1 i en t KeyExchang e 
Certif icateVerify* 
[ChangeCipher Spec ] 



Finished 



> 



[ChangeCipher Spec] 



< 



Finished 



Login Data 



< 



> 



Login HTML 
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* Indicates optional or situation -dependent 
messages that are not always sent. 

Figure 57 is a schematic illustration of a 
logical message format sent from the client browser to 
the desired middle tier server for a particular 
application. 

As mentioned herein, the messages created by 
the client applications (Java software) are transmitted 
to the secure Web Servers 24 over HTTPS. For incoming 
(client- to- server) communications, the Secure Web 
servers 24 decrypt a request, authenticate and verify 
the session information. The logical message format 
from the client to the Web server is shown as follows: 

|| TCP/IP || encryption || http || web header || 
dispatcher header || proxy- specific data || 

where separates a logical protocol level, and 

protocols nested from left to right. Figure 57 
illustrates a specific message sent from the client 
browser to the desired middle tier server for the 
particular application. As shown in Figure 57, the 
client message 170 includes an SSL encryption header 
171 and a network- level protocol HTTPP/POST header 172 
which are decrypted by the Secure Web Server (s) 24 to 
access the underlying message; ADMZ Web header 174 
which is used to generate a cookie 181 and transaction 
type identifier 186 for managing the client/server 
session; a dispatcher header 175 which includes the 
target proxy identifier 180 associated with the 
particular type of transaction requested; proxy 
specific data 185 including the application specific 
metadata utilized by the target proxy to form the 
particular messages for the particular middle tier 
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server providing a service; and, the network- level 
HTTP/POST trailer 186 and encryption trailer 188 which 
are also decrypted by the secure DMZ Web server 24. 

Referring back to Figure 2, after 
establishing that the request has come from a valid 
user and mapping the request to its associated session, 
the request is then forwarded through the firewall 25b 
over a socket connection 23 to one or more 
decode/dispatch servers 26 located within the corporate 
Intranet 30. The messaging sent to the Dispatch Server 
26 will include the user identifier and session 
information, the target proxy identifier, and the proxy 
specific data. The decode/dispatch server 26 then 
authenticates the user's access to the desired middle - 
tier service from cached data previously received from 
the StarOE server as will be hereinafter described in 
greater detail in connection with User Identification 
and Authentication. 

As shown in Figure 2, the Secure Web server 
24 forwards the Dispatcher header and proxy- specif ic 
data to the Dispatch Server 26 "enriched" with the 
identity of the user (and any other session- related 
information) as provided by the session data/cookie 
mapping, the target proxy identifier and the 
proxy/specific data. The dispatch server 26 receives 
the requests forwarded by the Secure Web server (s) 24 
and dispatches them to the appropriate application 
server or its proxy. The message wrappers are 
examined, revealing the user and the target middle -tier 
service for the request. A first- level validation is 
performed, making sure that the user is entitled to 
communicate with the desired service. The user's 
entitlements in this regard are fetched by the dispatch 
server from StarOE server 39 at logon time and cached. 
Assuming that the Requestor is authorized to 
communicate with the target service, the message is 
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then forwarded to the desired service's .proxy. Each of 
these proxy processes further performs: a validation 
process for examining incoming requests and confirming 
that they include validly formatted messages for the 
service with acceptable parameters; a translation 
process for translating a message into an underlying 
message or networking protocol; and, a management 
process for managing the communication of the specific 
customer request with the middle- tier server to 
actually get the request serviced. Data returned from 
the middle -tier server is translated back to client 
format, if necessary, and returned, to the dispatch 
server as a response to the requestor. 

It should be understood that the application 
server proxies can either reside, on the dispatch 
server 26 itself, or, preferably, can be resident on 
the middle -tier application server, i.e., the 
dispatcher front end code can locate proxies resident 
on other servers. 

Session Security 

As described previously, the SLL protocol 
includes one level of session security, and may 
negotiate and change in cipher code between sessions. 
Additionally, the present invention employs the 
"cookie" feature set of contemporary browsers to 
maintain session security, and prevent session 
hijacking or the use of a name and password obtain by 
sniffing, spoofing or EMR monitoring. 

Figure 58 is a data flow diagram illustrating 
data flow among the processing modules of the "network 
MCI Interact" during logon, entitlement 
request /response, heartbeat transmissions and logoff 
procedures. As shown in Figure 58, the client platform 
includes the networkMCI Interact user 20 representing a 
customer, a logon Web page having a logon object for 
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logon processing 220, a home page 79 having the 
backplane object. The Web server 24 , the dispatcher 
26, cookie jar server 28, and StarOE server 39 are 
typically located at the enterprise site. 

As described above, following the SSL 
handshake, certain cab files, class files and 
disclaimer requests are downloaded with the logon Web 
page as shown at 221. At the logon Web page, the 
customer 20 then enters a userid and password for user 
authentication as illustrated at 221. The customer 
also enters disclaimer acknowledgment 221 on the logon 
page 220. If the entered userid and password are not 
valid or if there were too many unsuccessful logon 
transactions, the logon object 220 communicates the 
appropriate message to the customer 20 as shown at 221. 
A logon object 220, typically an applet launched in the 
logon Web page, connects to the Web server 24, for 
communicating a logon request to the system as shown at 
222. The logon data, having an encrypted userid and 
password, is sent to the dispatcher 26 when the 
connection is established as shown at 224. The 
dispatcher 2 6 then decrypts the logon data and sends 
the data to the StarOE 39 after establishing a 
connection as shown at 26. The StarOE server 39 
validates the userid and password and sends the results 
back to the dispatcher 26 as illustrated at 226 
together with the user application entitlements. The 
dispatcher 2 6 passes the data results obtained from the 
StarOE 39 to the Web server 24 as shown at 224, which 
passes the data back to the logon object 220 as shown 
at 222. The customer 20 is then notified of the logon 
results as shown as 221. 

When the customer 20 is validated properly, 
the customer is presented with another Web page, 
referred to as the home page 79, from which the 
backplane is launched typically. After the user 



-279- 



WO 99/15979 



PCT/US98/20I70 



validation, the backplane generally manages the entire 
user session until the user logs off the "networkMCI 
Interact". As shown at 228, the backplane initiates a 
session heartbeat which is used to detect and keep the 
communications alive between the client platform and 
the enterprise Intranet site. The backplane also 
instantiates a COUser object for housekeeping of all 
client information as received from the StarOE 39. For 
example, to determine which applications a current 
customer is entitled to access and to activate only 
those application options on the home page for enabling 
the customer to select, the backplane sends a 
"get application list" message via the web server 24 
and the dispatcher 26 to the StarOE 39 as shown at 228, 
224, and 226. The entitlement list for the customer is 
then sent from the StarOE 39 back to the dispatcher 26, 
to the Web server 24 and to the backplane at the home 
page 79 via the path shown at 226, 224, and 228. The 
application entitlements for the customer are kept in 
the COUser object for appropriate use by the backplane 
and for subsequent retrieval by the client 
applications . 

The entitlement information for COUser is 
stored in a cookie jar 28, maintained in the cookie jar 
server 28 (illustrated in Figures 2 and 58) . When the 
Web server receives the entitlement requests from the 
backplane at the home page 79 or from any other client 
applications, the Web server 24 makes a connection to 
the cookie jar 28 and checks if the requested 
information is included in the cookie jar 28 as shown 
at 230. The cookie jar 28 is a repository for various 
customer sessions and each session details are included 
in a cookie including the entitlement information from 
the OE server 39. During the logon process described 
above, the OE server 39 may include in its response, 
the entitlements for the validated customer. The 
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dispatcher 26 transfers the entitlement data to the Web 
server 24, which translates it into a binary format. 
The Web server 24 then transmits the binary entitlement 
data to the cookie jar 28 for storage and retrieval for 
the duration of a session. Accordingly, if the 
requested information can be located in the cookie jar 
28, no further request to the StarOE 39 may be made. 
This mechanism cuts down on the response time in 
processing the request. Although the same inf ormation, 
for example, customer application entitlements or 
entitlements for corp ids, may be stored in the COUser 
object and maintains at the client platform as 
described above, a second check is usually made with 
the cookie jar 28 via the Web server 24 in order to 
insure against a corrupted or tampered COUser object's 
information. Thus, entitlements are typically checked 
in two places: the client platform 10 via COUser object 
and the Web server 24 via the cookie jar 28. 

When a connection is established with the 
cookie jar 28, the Web server 24 makes a request for 
the entitlements for a given session as shown at 23 0. 
The cookie jar 28 goes through its stored list of 
cookies, identifies the cookie for the session and 
returns the cookie to the Web server 24 also shown at 
23 0. The Web server 24 typically converts the 
entitlements which are received in binary format, to 
string representation of entitlements, and sends the 
entitlement string back to the backplane running on the 
client platform 10. 

Furthermore, the cookie jar 28 is used to 
manage heartbeat transactions. Heartbeat transactions, 
as described above, are used to determine session 
continuity and to identify those processes which have 
died abnormally as a result of a process failure, 
system crash or a communications failure, for example. 
During a customer session initialization, the cookie 
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jar 28 generates a session id and sets up "heartbeat" 
transactions for the customer's session. ^Subsequently, 
a heartbeat request is typically sent from a process 
running on a client platform to the Web server 24, when 
a connection is established, as shown at 228. The Web 
server 24 connects to the cookie jar 28 and requests 
heartbeat update for a given session. The cookie jar 
28 searches its stored list of cookies, identifies the 
cookie for the session and updates the heartbeat time. 
The cookie jar 28 then sends the Web server 24 the 
updated status heartbeat as shown at 230. The Web 
server 24 then sends the status back to the client 
platform process, also as shown at 230. 

When a customer wants to logoff, a logoff 
request transaction may be sent to the Web server 24. 
The Web server 24 then connects to the cookie jar 28 
and requests logoff for the session as shown at 230. 
The cookie jar 28 identifies the cookie for the session 
and deletes the cookie. After deleting the cookie, the 
cookie jar 28 sends a logoff status to the Web server 
24, which returns the status to the client platform. 

Other transaction requests are also sent via 
the Web server 24 and the cookie jar 28 as shown in 
Figure 59. Figure 59 is a data flow diagram for 
various transactions communicated in the system of the 
present invention. Typically, when a customer enters a 
mouse click on an application link as shown at 231, an 
appropriate transaction reguest stream is sent to the 
Web server as shown at 232. The Web server 24 
typically decrypts the transaction stream and connects 
to the cookie jar 28 to check if a given session is 
still valid as shown at 234. The cookie jar 28 
identifies the cookie for the session and sends it back 
to the Web server 24 as shown at 234. The Web server 
24 on receipt of valid session connects to the 
dispatcher 26 and sends the transaction request as 
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shown at 236. When the dispatcher 26 obtains the 
request, it may also connect to the cookie jar 28 to., 
validate the session as shown at 238. The cookie jar 
28 identifies the cookie for the session and sends it 
back to the dispatcher 26 as shown at 238. The 
dispatcher 26, upon receiving the valid session 
connects to a targeted application server or proxy 237, 
which may include StarOE, and sends the request 
transaction to the target proxy as shown at 235. The 
server or proxy 237 processes the request and sends 
back the response as stream of data which is piped back 
to the dispatcher 26 as shown at 235. The dispatcher 26 
pipes the data back to the Web server 24 as shown at 
236, which encrypts and pipes the data to the client 
platform as shown at 232, referred to as the home page 
79 in Figure 59 . 

The present invention includes a client 
communications unit for providing a single interface 
from which the backplane and the applications may send 
messages and requests to back-end services. The client 
communications unit includes a client session unit and 
a transactions unit. The client session unit and the 
transactions unit comprise classes used by client 
applications to create objects that handle 
communications to the various application proxies and 
or servers. Generally, the entire communications 
processes start with the creation of a client session 
after a login process. This is started through the 
login process. The user logs into user's Web page with 
a username and password. During a login process, a 
client session object of class COClientSession is 
created, and the COClientSession object passes the 
username and password information pair obtained from 
the login process to a remote system administrative 
service which validates the pair. The following code 



-283- 



WO 99/15979 



PCT/US98/20170 



instructions are implemented, for example, to start up 
a session using the COClientSession class. 
COClientSession ss = new COClientSession () ; 
try { 

ss. setURL(urlString) ; 
ss . logon ( " j smith" , "myPassword" ) ; 
} catch (COClientLogonException e) {... 
} catch (Malf ormedURLException e) {...}; 
In addition, the COClientSession object 
contains a reference to a valid COUser object 
associated with the user of the current COClientSession 
object . 

The client session object also provides a 
session, where a customer logs on to the system at the 
start of the session, and if successfully 
authenticated, is authorized to use the system until 
the session ends. The client session object at the 
same time provides a capability to maintain session - 
specific information for the life/duration of the 
session. Generally, communications to and from the 
client takes place over HTTPS which uses the HTTP 
protocols over an SSL encrypted channel. Each HTTP 
request/reply is a separate TCP/IP connection, 
completely independent of all previous or future 
connections between the same server and client. 
Because HTTP is stateless, meaning that each connection 
consists of a single request from the client which is 
answered by a single reply by a server, a novel method 
is provided to associate a given HTTP request with the 
logical session to which it belongs. 

When a user is authenticated at login via the 
system administrative server, the client session object 
is given a "cookie", a unique server- generated key 
which identifies a session. The session key is 
typically encapsulated in a class COWebCookie, "public 
COWebCookie (int value).", where value represents a 
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given cookie's value. The client session object holds 
this key and returns it to the server as part of the 
subsequent HTTP request. The Web server maintains a 
"cookie jar" which is resident on the dispatch server 
and which maps these keys to the associated session. 
This form of session management also functions as an 
additional authentication of each HTTPS request, adding 
security to the overall process. In the preferred 
embodiment, a single cookie typically suffices for the 
entire session. Alternatively, a new cookie may be 
generated on each transaction for added security. 
Moreover, the cookie jar may be shared between the 
multiple physical servers in case of a failure of one 
server. This mechanism prevents sessions being dropped 
on a server failure. 

In addition, to enable a server software to 
detect client sessions which have "died", e.g., the 
client session has been disconnected from the server 
without notice because of a client -side crash or 
network problem, the client application using the 
client session object "heartbeats" every predefined 
period, e.g., 1 minutes to the Web server to "renew" 
the session key (or record) . The Web server in turn 
makes a heartbeat transaction request to the cookie 
jar. Upon receipt of the request, the cookie jar 
service "marks" the session record with a times tamp 
indicating the most recent time the client communicated 
to the server using the heartbeat. The cookie jar 
service also alarms itself, on a configurable period, 
to read through the cookie jar records (session keys) 
and check the times tamp (indicating the time at which 
the client was last heard) against the current time. 
If a session record's delta is greater than a 
predetermined amount of time, the cookie jar service 
clears the session record, effectively making a session 
key dead. Any subsequent transactions received with a 



-285- 



WO 99/15979 



PCT/US98/20170 



dead session key, i.e., nonexistent in the cookie jar, 
are forbidden access through the Firewall. 

The heartbeat messages are typically enabled 
by invoking the COClientSession objects method "public 
synchronized void enableSessionHeartbeat (boolean 
enableHeartbeat) " , where enableHeartbeat is a flag to 
enable or disable heartbeat for a session. The 
heartbeat messages are typically transmitted 
periodically by first invoking the COClientSession 
object 's method "public synchronized void 
setHeartbeatlnterval (long millsecslnterval) " , where 
the heartbeat interval is set in milliseconds, and by 
the COClientSession object's method "protected int 
startHeartbeat ( ) " , where the heartbeat process starts 
as soon as the heartbeat interval is reached. Failure 
to "heartbeat" for consecutive predefined period, e.g., 
one hour, would result in the expiration of the session 
key. 

Enterprise Security 

Enterprise Security is directed to the 
security of the enterprise network and the data 
maintained by the various enterprise applications with 
respect to the open nature of the Internet, and the 
various attacks on the system or data likely to result 
from exposure to the Internet. Usual enterprise 
security is focused on internal procedures and 
employees, since this represents the biggest single 
area of exposure. Strong passwords, unique user Ids 
and the physical security the workstations are 
applicable to both internal employees and external 
customers and users who will access the enterprise 
applications. It is noted that many of the previously 
described features relating to data encryption for 
communications security and session security are 
essential parts of enterprise security, and cooperate 
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with enterprise architecture and software 
infrastructure to provide security for the enterprise. 

For example, as will be hereinafter described 
in detail, the present invention uses strong symmetric 
key encryption for communications through the firewalls 
to the application servers. This internal symmetric 
key encryption, when coupled with external public key 
encryption provides an extra level of security for both 
the data and the software infrastructure. 

Figure 60 is a diagram depicting the physical 
networkMCI Interact system architecture 100. As shown 
in Figure 60, the system is divided into three major 
architectural divisions including: 1) the customer 
workstation 20 which include those mechanisms enabling 
customer connection to the Secure web servers 24; 2) a 
secure network area 17, known as the DeMilitarized Zone 
"DMZ" set aside on MCI premises double firewalled 
between the both the public Internet 25 and the MCI 
Intranet to prevent potentially hostile customer 
attacks; and, 3) the MCI Intranet Midrange Servers 30 
and Legacy Mainframe Systems 40 which comprise the back 
end business logic applications. 

As illustrated in Figure 60, a double or 
complex firewall system defines a "demilitarized zone" 
(DMZ) between two firewalls 25a, 25b. In the preferred 
embodiment, one of the firewalls 25 includes port 
specific filtering routers, which may only connect with 
a designated port on a dispatch server within the DMZ. 
The dispatch server connects with an authentication 
server, and through a proxy firewall to the application 
servers. This ensures that even if a remote user ID 
and password are hijacked, the only access granted is 
to one of the web servers 24 or to intermediate data 
and privileges authorized for that user. Further, the 
hijacker may not directly connect to any enterprise 
server in the enterprise intranet, thus ensuring 
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internal company system security and integrity. Even 
with a stolen password, the hijacker may not connect to 
other ports, root directories or applications within 
the enterprise system. 

The DMZ acts as a double firewall for the 
enterprise intranet because the web servers located in 
the DMZ never store or compute actual customer 
sensitive data. The web servers only put the data into 
a form suitable for display by the customer's web 
browser. Since the DMZ web servers do not store 
customer data, there is a much smaller chance of any 
customer information being jeopardized in case of a 
security breach. 

As previously described, the customer access 
mechanism is a client workstation 20 employing a Web 
browser 14 for providing the access to the networkMCI 
Interact system via the public Internet 15. When a 
subscriber connects to the networkMCI Interact Web site 
by entering the appropriate URL, a secure TCP/IP 
communications link 22 is established to one of several 
Web servers 24 located inside a first firewall 25a in 
the DMZ 17. Preferably at least two web servers are 
provided for redundancy and failover capability. In 
the preferred embodiment of the invention, the system 
employs SSL encryption so that communications in both 
directions between the subscriber and the networkMCI 
Interact system are secure. 

In the preferred embodiment, all DMZ Secure 
Web servers 24 are preferably DEC 4100 systems having 
Unix or NT -based operating systems for running services 
such as HTTPS, FTP, and Telnet over TCP/IP. The web 
servers may be interconnected by a fast Ethernet LAN 
running at 100 Mbit/sec or greater, preferably with the 
deployment of switches within the Ethernet LANs for 
improved bandwidth utilization. One such switching 
unit included as part of the network architecture is a 
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HydraWEB™ unit 45, manufactured by HydraWEB 
Technologies, Inc., which provides the DMZ with a 
virtual IP address so that subscriber HTTPS requests 
received over the Internet will always be received. 
The Hydraweb™ unit 45 implements a load balancing 
algorithm enabling intelligent packet routing and 
providing optimal reliability and performance by 
guaranteeing accessibility to the "most available" 
server. It particularly monitors all aspects of web 
server health from CPU usage, to memory utilization, to 
available swap space so that Internet/Intranet networks 
can increase their hit rate and reduce Web server 
management costs. In this manner, resource utilization 
is maximized and bandwidth (throughput) is improved. 
It should be understood that a redundant Hydraweb™ unit 
may be implemented in a Hot/Standby configuration with 
heartbeat messaging between the two units (not shown) . 
Moreover, the networkMCI Interact system architecture 
affords web server scaling, both in vertical and 
horizontal directions. Additionally, the architecture 
is such that new secure web servers 24 may be easily 
added as customer requirements and usage increases. 
The use of the HydraWEB™ enables better load 
distribution when needed to match performance 
requirements . 

As shown in Figure 60, the most available web 
server 24 receives subscriber HTTPS requests, for 
example, from the HydraWEB™ 45 over a connection 3 5a 
and generates the appropriate encrypted messages for 
routing the request to the appropriate MCI Intranet 
midrange web server over connection 35b, router 55 and 
connection 23. Via the Hydraweb™ unit 45, a TCP/IP 
connection 38 links the Secure Web server 24 with the 
MCI Intranet Dispatcher server 26. 

Further as shown in the DMZ 17 is a second 
RTM server 52 having its own connection to the public 
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Internet via a TCP/IP connection 32. This server 
provides real-time session management for subscribers 
of the networkMCI Interact Real Time Monitoring system. 
An additional TCP/IP connection 48 links the RTM Web 
server 52 with the MCI Intranet Dispatcher server 26. 

With more particularity, as further shown in 
Figure 60, the networkMCI Interact physical 
architecture includes two routers: a first router 55 
for routing encrypted subscriber messages from a Secure 
Web server 24 to the Dispatcher server 26 located 
inside the second firewall 25b; and, a second router 65 
for routing encrypted subscriber messages from the RTM 
Web server 52 to the Dispatcher server 26 inside the 
second firewall. Although not shown, each of the 
routers 55, 6 5 may additionally route signals through a 
series of other routers before eventually being routed 
to the nMCI Interact Dispatcher server 26. In 
operation, each of the Secure servers 24 function to 
decrypt the client message, preferably via the SSL 
implementation, and unwrap the session key and verify 
the users session from the COUser object authenticated 
at Logon. 

After establishing that the request has come 
from a valid user and mapping the request to its 
associated session, the Secure Web servers 24 will 
re -encrypt the request using symmetric RSA encryption 
and forward it over a second secure socket connection 
23 to the dispatch server 26 inside the enterprise 
Intranet . 

Figure 61(a) and 61(b) are schematic 
illustrations showing the message format passed between 
the dispatcher 26 and the relevant application specific 
proxy, (Figure 61(a)) and the message format passed 
between the application specific proxy back to the 
Dispatcher 26 (Figure 61(b)). As shown in Figure 
61(a), all messages between the Dispatcher and the 
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Proxies, in both directions, begin with a common header 
140 to allow leverage of common code for processing the 
messages. A first portion of the header includes the 
protocol version 141 which may comprise a byte of data 
for identifying version control for the protocol, i.e., 
the message format itself, and is intended to prevent 
undesired mismatches in versions of the dispatcher and 
proxies. The next portion includes the message length 
142 which, preferably, is a 32 -bit integer providing 
the total length of the message including all headers. 
Next is the echo/ping flag portion 143 that is intended 
to support a connectivity test for the dispatcher -proxy 
connection. For example, when this flag is non-zero, 
the proxy immediately replies with an echo of the 
supplied header. There should be no attempt to connect 
to processes outside the proxy, e.g. the back-end 
application services. The next portion indicates the 
Session key 144 which is the unique session key or 
"cookie" provided by the Web browser and used to 
uniquely identify the session at the browser. As 
described above, since the communications middleware is 
capable of supporting several types of transport 
mechanisms, the next portion of the common protocol 
header indicates the message type/mechanism 145 which 
may be one of four values indicating one of the 
following four message mechanisms and types: 

1) Synchronous transaction, e.g., a binary 0; 

2) Asynchronous request, e.g., a binary 1; 

3) Asynchronous poll/reply, e.g., a binary 2; 

4) bulk transfer, e.g., a binary 3. 

Additionally, the common protocol header 
section includes an indication of dispatcher -assigned 
serial number 146 that is unique across all dispatcher 
processes and needs to be coordinated across processes 
(like the Web cookie (see above)), and, further, is 
used to allow for failover and process migration and 
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enable multiplexing control between the proxies and 
dispatcher, if desired. A field 147 indicates the 
status is unused in the request header but is used in 
the response header to indicate the success or failure 
of the requested transaction. More complete error data 
will be included in the specific error message 
returned. The status field 147 is included to maintain 
consistency between requests and replies. As shown in 
Figure 61(a), the proxy specific messages 148 are the 
metadata message requests from the report requestor 
client and can be transmitted via synchronous, 
asynchronous or bulk transfer mechanisms. Likewise, 
the proxy specific responses are metadata response 
messages 149 again, capable of being transmitted via a 
synch, asynch or bulk transfer transport mechanism. 

It should be understood that the application 
server- proxies can either reside on the dispatch server 
26 itself, or, preferably, can be resident on the 
middle-tier application servers 30, i.e., the 
dispatcher front end code can locate proxies resident 
on other servers . 

As mentioned, the proxy validation process 
includes parsing incoming requests, analyzing them, and 
confirming that they include validly formatted messages 
for the service with acceptable parameters. If 
necessary, the message is translated into an underlying 
message or networking protocol . If no errors are 
found, the proxy then manages the communication with 
the middle- tier server to actually get the request 
serviced. The application proxy supports application 
specific translation and communication with the back- 
end application server for both the Web Server (java 
applet originated) messages and application server 
messages . 

For example, in performing the verification, 
translation and communication functions, the Report 
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server proxies (Figure 10) each employ front end proxy 
C++ objects and components. For instance, a utils.c 
program and a C++ components library, is provided for 
implementing general functions/objects. Various C++ 
parser objects are invoked which are part of an object 
class used as a repository for the RM metadata and 
parses the string it receives. The class has a build 
member function which reads the string which contains 
the data to store. After a message is received, the 
parser object is created in the RMDispatcher .c object 
which is file containing the business logic for 
handling metadata messages at the back-end. It uses 
the services of an RMParser class. Upon determining 
that the client has sent a valid message, the 
appropriate member function is invoked to service the 
request. Invocation occurs in MCIRMServerSocket .C when 
an incoming message is received and is determined not 
to be a Talarian message. RMSErverSocket . c is a class 
implementing the message management feature in the 
Report Manager server. Public inheritance is from 
MCIServerSocket in order to create a specific instance 
of this object. This object is created in the main 
loop and is called when a message needs to be sent and 
received; a Socket. c class implementing client type 
sockets under Unix using, e.g., TCP/IP or TCP/UDP. 
Socket. C is inherited by ClientSocket .C : : 
Socket (theSocketType, thePortNum) and ServerSocket .C : : 
Socket (theSocketType, thePortNum) when ClientSocket or 
ServerSocket is created. A ServerSocket . c class 
implements client type sockets under Unix using either 
TCP/IP or TCP/UDP. ServerSocket . C is inherited by 
RMServerSocket when RMServerSocket is created. An 
InboxParser .c class used as a repository for the RM 
Metadata. The class 1 "build" member function reads the 
string which contains the data to store and the class 
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parses the string it receives. After a message has 
been received, the MCIInboxParser object is created in 
inboxutl.c which is a file containing the functions 
which process the Inbox requests, i.e, Add, Delete, 
List, Fetch and Update. Additional objects/classes 
include: Environ. c which provides access to a UNIX 
environment; Process. c which provides a mechanism to 
spawn slave processes in the UNIX environment; Daemon. c 
for enabling a process to become a daemon; Exception. c 
for exception handling in C++ programs; and, RMlog.c 
for facilitating RM logging. In addition custom ESQL 
code for RM/database interface is provided which 
includes the ESQC C interface (Informix) stored 
procedures for performing the ARD, DRD, DUR, URS, GRD, 
CRD, and GPL messages. The functions call the stored 
procedures according to the message, and the response 
is build inside the functions depending on the returned 
values of the stored procedures. A mainsql.c program 
provides the ESQL C interface for messages from the 
report manager and report viewer. 

Outgoing (server- to- client) communications 
follow the reverse route, i.e., the proxies feed 
responses to the decode/dispatch server 26 and 
communicate them to the DMZ Web servers 24 over the 
socket connection. The Web servers 26 will forward the 
information to the client 10 using SSL. The logical 
message format returned to the client from the middle 
tier service is shown as follows: 
| | TCP/IP | | encryption | | http | | web response | | 
dispatcher response | | proxy- specif ic response | | 
where "||" separates a logical protocol level, and 
protocols nested from left to right. 

While the invention has been particularly 
shown and described with respect to preferred 
embodiments thereof, it will be understood by those 
skilled in the art that the foregoing and other changes 
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departing from the spirit and scope of the invention. 
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WHAT IS CLAIMED Tfl ; 

1 1. An integrated and secure system for 

2 conducting business over the public Internet by 

3 enabling a customer of an enterprise communications 

4 network to command and control the customer's switched 

5 communications connections within the network over the 

6 public Internet and to view the results of any changes 

7 in the customer's connections over the public Internet, 

8 said system comprising: 

9 (a) an object oriented protocol for enabling 

10 encrypted interactive communications between said 

11 system and said customer over the public Internet, said 

12 protocol invoked within said customers web browser to 

13 support encryption, customer identification, 

14 authentication and network entitlements; 

15 (b) at least one secure web server for 
•6 managing secure customer sessions over the public 

17 Internet, said secure server providing session 

18 management for the customer connection, said session 

19 management including customer identification, 

20 validation, entitlements and encryption; 

21 (c) at least one dispatch server for 

22 communicating with said secure web server and a 

23 plurality of system resources, said dispatch server 

24 providing verification of system access and proxy 

25 generation for said system resources after said 

26 customer's entitlements have been verified; 

27 (d) said plurality of system resources 

28 including a network manager which manages the routing 

29 of the customer's traffic over the communications 

30 network, and a view application to review said network 

31 traffic, said network manager and said view application 

32 responsive to proxy requests from said dispatch server 

33 to enable the customer to command and control the 
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1 communications network resources provided by the 

2 enterprise to the customer. 

1 2. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 1, wherein said switched communications 

4 connections further includes switched voice traffic and 

5 said network manager may command and control said 

6 switched voice traffic. 

1 3 . The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 2, wherein said switched voice traffic further 

4 includes switched toll free voice traffic and said 

5 network manager includes a toll free network manager 

6 application to command and control the routing of said 

7 switched voice traffic. 

1 4. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 2, wherein said switched voice 

4 traffic further includes switched call center voice 

5 traffic and said network manager includes a call 

6 manager application to command and control the routing 

7 of said switched voice traffic between call centers. 

1 5. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 2, wherein said network manager includes an 

4 outbound network manager to command and control said 

5 switched toll traffic. 

1 6. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 1, wherein said switched communications 

4 connections further includes switched voice and data 
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1 communications and said network manager may command and 

2 control said switched voice communications. 

1 7. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 1, wherein said switched communications 

4 connections further includes switched voice traffic and 

5 said view application includes a reporter for 

6 generating reports on the switched voice communications 

7 in said network traffic. 

1 .8. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 7, wherein said reporter for generating 

4 reports on the switched voice communications in said 

5 network traffic includes a real time reporter for 

6 generating reports on said network traffic in near real 

7 time. 

1 9 . The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 7 , wherein said reporter for generating 

4 reports on the switched voice communications in said 

5 network traffic includes a real time reporter for 

6 generating reports on outbound network traffic in near 

7 real time. 

1 10. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 7 , wherein said reporter for generating 

4 reports on the switched voice communications in said 

5 network traffic includes a reporter for generating 

6 history reports on said switched voice communications 

7 occurring during preselected periods of time. 
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11. The integrated and secure system for 
conducting business over the public Internet as claimed 
in Claim 7, wherein said reporter for generating 
reports on the switched voice communications in said 
network traffic includes a report manager application 
for enabling a customer to generate reports for a 
plurality of switched voice communication applications 
and an in -box manager application for communicating the 
reports to the customer. 

12. The integrated and secure system for 
conducting business over the public Internet as claimed 
in Claim 7, wherein said reporter for generating 
reports on the switched voice communications in said 
network traffic includes a priced call application for 
enabling a customer to generate priced reports and 
invoices for a plurality of switched voice 
communication applications. 

13. The integrated and secure system for 
conducting business over the public Internet as claimed 
in Claim 1, wherein said customer's switched 
communications connections includes switched data 
traffic and said view application to view said switched 
data traffic includes a broadband view application for 
generating reports on data relating to the switched 
data traffic. 

14. The integrated and secure system for 
conducting business over the public Internet as claimed 
in Claim 6, wherein said system includes an in-box 
application for storing and forwarding reports to the 
customer on data relating to the customer's switched 
voice and data traffic. 



-299- 



WO 99/15979 



PCT/US98/20170 



1 15. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 1, wherein said system includes an event 

4 monitor application for storing and forwarding alarms 

5 generated with respect to the customer's traffic over 

6 the communications network. 

1 16. The integrated and secure system for 

2 conducting business over the public Internet by 

3 enabling a customer of an enterprise communications 

4 network to obtain and view reports over the public 

5 Internet relating to a plurality of services provided 

6 to the customer by the enterprise network, said system 

7 comprising: 

8 (a) an object oriented protocol for enabling 

9 encrypted interactive communications between said 

10 system and said customer over the public Internet, said 

11 protocol invoked within said customers web browser to 

12 support encryption, customer identification, 

13 authentication and report entitlements; 

14 (b) at least one secure web server for 

15 managing secure customer sessions over the public 

16 Internet, said secure server providing session 

1 7 management for the customer connection, said session 
IS management including customer identification, 

19 validation, report entitlements and encryption; 

20 (c) at least one dispatch server for 

21 communicating with said secure web server and a 

22 plurality of system resources, said dispatch server 

23 providing verification of system access and proxy 

24 generation for said reports after said customer's 

25 entitlements have been verified, each of said system 

26 resources maintaining data relating to separate 

27 communications network services provided to the 

2 8 customer by the enterprise; 

29 (d) a report requestor for enabling the 
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1 customer to request reports from said plurality of 

2 system resources provided by the enterprise to the 

3 customer, a customer in-box for providing the reports 

4 to the customer, and a report viewer for presenting the 

5 reports to the customer, said report requestor, said 

6 customer in-box and said reort viewer responsive to 

7 proxy requests from said dispatch server to enable the 

8 customer to obtain and view reports from data 

9 maintained by a plurality of system resources from a 

10 single point of customer contact, identification and 

11 authentication, 

1 17. The integrated and secure system for 

2 conducting business over the public Internet as 

3 claimed in Claim 16, wherein said report requestor 

4 provides a single tool set for requesting and 

5 scheduling reports across a plurality of system 

6 resources. 

1 18. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 16, wherein said reports are historical 

4 reports on the customer's switched voice traffic. 

1 19. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 16, wherein said reports are priced call 

4 reports on the customer's switched communications 

5 connections. 

1 20. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 19, wherein said reports are invoices 

4 generated with respect to the customer's switched 

5 communications connections. 
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1 21. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 20, wherein said system further includes an 

4 electronic fund transfer application to enable payment 

5 of the invoices generated with respect to the 

6 customer's switched communications connections. 

1 22. The integrated and secure system for 

2 conducting business over the public Internet by 

3 enabling a customer of an enterprise communications 

4 network to obtain event reports over the public 

5 Internet relating to a plurality of services provided 

6 to the customer by the enterprise network, said system 

7 comprising: 

8 (a) an object oriented protocol for enabling 

9 encrypted interactive communications between said 

10 system and said customer over the public Internet, said 

11 protocol invoked within said customers web browser to 

12 support encryption, customer identification, 

13 authentication and report entitlements; 

14 (b) at least one secure web server for 

15 managing secure customer sessions over the public 

16 Internet, said secure server providing session 

17 management for the customer connection, said session 

18 management including customer identification, 

19 validation, report entitlements and encryption; 

20 (c) at least one dispatch server for 

21 communicating with said secure web server and a 

22 plurality of system resources, said dispatch server 

23 providing verification of system access and proxy 

24 generation for said reports after said customer's 

25 entitlements have been verified, each of said system 

26 resources maintaining data relating to separate 

27 communications network services provided to the 

28 customer by the enterprise; 
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1 (d) an event monitor application for 

2 enabling the customer to monitor a plurality of system 

3 resources provided by the enterprise to the customer, 

4 said event monitor application providing said customer 

5 with data necessary to make informed network management 

6 decisions with respect to said plurality of system 

7 resources from a single point of customer contact, 

8 identification and authentication. 

1 23. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 22, wherein said event monitor includes a 

4 report manager for requesting and scheduling reports on 

5 events occurring within the customers switched 

6 communication connections, 

1 24. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 22, wherein said event monitor includes a 

4 report manager for requesting and scheduling reports on 

5 events occurring within the customers switched data 

6 communication connections. 

1 25. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 22 wherein said event monitor provides 

4 customer access to a plurality of reports on 

5 trouble tickets opened on events occurring within the 

6 customers switched communication connections. 

1 26. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 22, wherein said system further includes a 

4 toll free network manager as one of said plurality of 

5 system resources, and said manager provides reports on 

6 the customers switched toll free voice connections. 
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1 27. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 22, wherein said system further includes a 

4 call center manager as one of said plurality of system 

5 resources, and said call center manager provides 

6 reports on the customers switched call center 

7 connections. 

1 28. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 22, wherein said system further includes an 

4 out bound network manager as one of said plurality of 

5 system resources, and said outbound network manager 

6 providing reports on the customers outbound network 

7 calls. 

1 29. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 28, wherein said system further includes a 

4 single order entry application and an out bound network 

5 manager as two of said plurality of system resources, 

6 wherein said order entry application enables a customer 

7 to identify and authenticate a plurality of users with 

8 distinct call entitlements, and to modify said 

9 entitlements from a single point of customer 

10 identification and authentication, said outbound 

11 network manager providing modification of individual 

12 users entitlements for outbound network calls in 

13 response to entitlements determined by said order entry 

14 application. 

1 30. The integrated and secure system for 

2 conducting business over the public Internet by 

3 enabling a customer of an enterprise communications 

4 network to modify the customer's business relationship 

5 with the enterprise over the public Internet and to 
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1 add, delete and modify services provided by the 

2 enterprise communications network to the customer, said 

3 system comprising: 

4 (a) an object oriented protocol for enabling 

5 encrypted interactive communications between said 

6 system and said customer over the public Internet, said 

7 protocol invoked within said customers web browser to 

8 support encryption, customer identification, 

9 authentication and network entitlements; 

10 (b) at least one secure web server for 

11 managing secure customer sessions over the public 

12 Internet, said secure server providing session 

13 management for the customer connection, said session 

14 management including customer identification, 

15 validation, entitlements and encryption; 

16 (c) at least one dispatch server for 

17 communicating with said secure web server and a 

18 plurality of system resources, said dispatch server 

19 providing verification of system access and proxy 

20 generation for said interactive communications after 

21 said customer's entitlements have been verified; 

22 (d) said plurality of system resources 

23 including an order entry application which enables the 

24 customer to add, delete and modify services provided by 

25 the communications network to the customer, and to 

26 identify and authenticate a plurality of users with 

27 distinct call entitlements, and to modify said 

28 entitlements from a single point of customer 

29 identification and authentication, said order entry 

30 application responsive to proxy requests from said 

31 dispatch server to enable the customer to manage the 

32 communications network services provided by the 

33 enterprise to the customer. 

1 31. The integrated and secure system for 

2 conducting business over the public Internet as claimed 
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1 in Claim 30, wherein said system further comprises an 

2 E- Billing application which enables electronic business 

3 transactions to pay for said services, said order entry 

4 and E-Billing applications responsive to proxy requests 

5 from said dispatch server to enable the customer to 

6 manage and pay for the communications network services 

7 provided by the enterprise. 

1 32. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 31, wherein said system further includes a 

4 client view application foT generating historical 

5 reports of data relating to calls by customers users on 

6 said communications network. 

1 33. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 32, wherein said system enables invoice 

4 generation and electronic payment for preselected 

5 customer user calls over the public Internet. 

1 34. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 30, wherein said system further includes a 

4 toll free network manager as one of said plurality of 

5 resources, and said order entry application enables a 

6 customer to identify and authenticate a plurality of 

7 users with distinct toll free call routing 

8 entitlements, and to modify said toll free call routing 

9 entitlements from a single point of customer 
10 identification and authentication. 

1 35. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 30, wherein said system further includes a 

4 call center manager application as one of said 
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1 plurality of resources, and said order entry 

2 application enables a customer to identify and 

3 authenticate a plurality of users with .distinct call 

4 center routing entitlements, and to modify said call 

5 center routing entitlements from a single point of 

6 customer identification and authentication. 

1 36. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 30, wherein said system further includes an 

4 event monitor application as one of said plurality of 

5 resources . 

1 37. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 36, wherein said system further includes a 

4 broadband view application for reporting on data 

5 communications connections, and said event monitor 

6 application reports alarm events occurring with respect 

7 said customers data communications connections. 

1 38. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 36, wherein said system further includes a 

4 service inquiry application for managing trouble 

5 tickets venerated with respect to said customers 

6 communications connections, and said order entry 

7 application allows modification of user entitlements 

8 with respect to said trouble tickets. 

1 39. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 30, wherein said system further includes a 

4 real time monitor application as one of said plurality 

5 of resources. 
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1 40. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 31 , wherein said system further includes a 

4 client view application for generating historical 

5 reports of data relating to calls by customers users on 

6 said communications network, and said E- Billing 

7 application enables electronic fund transfers for 

8 payment of said calls by said customer. 

1 41. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 40, wherein said system further includes a 

4 priced reporting application for generating invoices 

5 for said calls. 

1 42. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 30, wherein said plurality of system resources 

4 includes a network manager which enables command and 

5 control of the customer's traffic over the enterprise 

6 communications network, and a viewing application to 

7 represent said network traffic, said network manager 

8 and said viewing application responsive to proxy 

9 requests from said dispatch server to enable the 

10 customer to command and control the communications 

11 network resources provided by the enterprise to the 

12 customer. 

1 43. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 42, wherein said customer's traffic further 

4 includes switched voice traffic and said network 

5 manager may command and control said switched voice 

6 traffic. 
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1 44 . The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 43, wherein said switched voice traffic 

4 further includes switched toll free voice traffic and 

5 said network manager includes a toll free network 

6 manager application to command and control the routing 

7 of said switched voice traffic. 

1 45. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 43, wherein said switched voice traffic 

4 further includes switched call center voice traffic and 

5 said network manager includes a call manager 

6 application to command and control the routing of said 

7 switched voice traffic between call centers. 

1 46. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 43, wherein said switched voice traffic 

4 further includes switched toll voice traffic and said 

5 network manager includes an outbound network manager to 

6 command and control said switched toll traffic. 

1 47. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 42, wherein said customer's traffic further 

4 includes switched data communications and said viewing 

5 application may view data representative of said 

6 switched data communications. 

1 48. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 42, wherein said customers traffic further 

4 includes switched voice traffic and said viewing 

5 application includes a reporter for generating reports 
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1 on the switched voice communications in said network 

2 traffic. 

1 49. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 48, wherein said reporter for generating 

4 reports on the switched voice traffic in said network 

5 traffic includes a real time reporter for generating 

6 reports on said network traffic in near real time. 

1 50. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 48, wherein said reporter for generating 

4 reports on the switched voice traffic in said network 

5 traffic includes a reporter for generating history 

6 reports on said switched voice traffic occurring during 

7 preselected periods of time. 

1 51. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 48 , wherein said reporter for generating 

4 reports on the switched voice communications in said 

5 network traffic includes a report manager application 

6 for enabling a customer to generate reports for a 

7 plurality of switched voice traffic applications and an 

8 in-box manager application for communicating the 

9 reports to the customer. 

1 52. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 48 , wherein said reporter for generating 

4 reports on the switched voice traffic in said network 

5 traffic includes a priced call application for enabling 

6 a customer to generate priced reports and invoices for 

7 a plurality of switched voice traffic applications. 
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1 53. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 47, wherein said viewing application to view 

4 said switched data communications includes a broadband 

5 view application for generating reports on data 

6 relating to the switched data communications. 

1 54 . The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 47, wherein said system further includes an 

4 in -box application for storing and forwarding reports 

5 to the customer on data relating to the customer ! s 

6 switched data communications. 

1 55. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 47, wherein said viewing application includes 

4 an event monitor application for storing and forwarding 

5 reports on alarm reports generated with respect to the 

6 customer's switched data communications. 

1 56. The integrated and secure system for 

2 conducting business over the public Internet by 

3 enabling a customer of an enterprise communications 

4 network to modify the customer's switched voice 

5 communications connections within the network over the 

6 public Internet and to monitor the results in near real 

7 time over the public Internet, said system comprising: 

8 (a) an object oriented protocol for enabling 

9 interactive communications between said system and said 
10 customer over the public Internet, said protocol 

H invoked within said customers web browser to support, 

12 customer identification, authentication and network 

13 entitlements; 

* 4 (b) at least one secure web server for 

15 managing secure customer sessions over the public 
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1 Internet, said secure server providing session 

2 management for the customer connection, said session 

3 management including customer identification, 

4 validation, entitlements and encryption; 

5 (c) at least one dispatch server for 

6 communicating with said secure web server and a 

7 plurality of system resources, said dispatch server 

8 providing verification of system access and proxy 

9 generation for said interactive communications after 

10 said customer's entitlements have been verified; 

11 (d) said plurality of system resources 

12 including a toll free network manager which manages 

13 the routing of the customer's toll free voice traffic 

14 over the communications network, and a real time 

15 monitor which provides near real time monitoring of 

16 network traffic, said network manager and said real 

17 time monitor responsive to proxy requests from said 

18 dispatch server to enable the customer to manage the 

19 communications network resources provided by the 

20 enterprise to the customer in near real time. 

1 57. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 56, wherein said system further includes a 

4 single order entry application as one of said plurality 

5 of system resources, wherein said order entry 

6 application enables a customer to identify and 

7 authenticate a plurality of users with distinct toll 

8 free call manager entitlements, and to modify said 

9 entitlements from a single point of customer 
10 identification and authentication. 

1 58. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 57, wherein said system further comprises an 

4 E-Billing application which enables electronic business 
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1 transactions to pay for said services, said order entry 

2 and E- Billing applications responsive to proxy requests 

3 from said dispatch server to enable the customer to 

4 manage and pay for the communications network services 

5 provided by the enterprise. 

1 59 . The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 56, wherein said system further includes a 

4 client view application for generating historical 

5 reports of data relating to calls by customers users on 

6 said communications network. 

1 60. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 56, wherein said system enables invoice 

4 generation and electronic payment for preselected 

5 customer user calls over the public Internet. 

1 61. The integrated and secure method for 

2 conducting business over the public Internet by 

3 enabling a customer of an enterprise communications 

4 network to command and control the customer's switched 

5 communications connections within the network over the 

6 public Internet and to monitor the results in near real 

7 time over the public Internet, said system comprising: 

8 (a) enabling interactive communications 

9 between said system and said customer over the public 

10 Internet with an object oriented protocol invoked from 

11 within said customer's web browser, said protocol 

12 supporting customer identification, authentication and 

13 a determination of network entitlements for the 

14 customer; 

15 (b) managing a plurality of customer 

16 sessions over the public Internet with a secure web 

17 server, said secure web server providing session 
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1 encryption and management of the customer's session, 

2 said session management including the steps of 

3 identifying, validating, and determining the customer's 

4 entitlements within the network; 

5 (c) communicating with a plurality of system 

6 resources through dispatch server, said dispatch server 

7 communicating with said secure web server and providing 

8 verification of system access and proxy generation for 

9 said interactive communications after said customer's 

10 entitlements have been verified; 

11 (d) managing a plurality of enterprise 

12 system resources for the customer, said resources 

13 including a toll free network manager which manages the 

14 routing of the customer's toll free voice traffic over 

15 the communications network, and a real time monitor 

16 which provides near real time monitoring of network 

17 traffic; 

18 (e) converting a customer request to modify 

19 a routing plan to a proxy request for said toll free 

20 network manager and providing near real time 

21 monitoring of the customers' s voice traffic to enable 

22 the customer to manage the communications network 

23 resources provided by the enterprise to the customer in 

24 near real time. 

1 62. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 61, wherein said method further includes 

4 entering customer orders through a single order entry 

5 point of authorization to enable the customer to 

6 identify and authenticate a plurality of users, with 

7 each user having distinct toll free call routing 

8 entitlements, and to modify said entitlements from said 

9 single point of customer identification and 
10 authentication. 
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1 63. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 62 , wherein said method further incudes 

4 enabling payment with an E-Billing application, said 

5 order entry and E-Billing applications responsive to 

6 proxy requests from said dispatch server to enable the 

7 customer to manage and pay for the communications 

8 network services provided by the enterprise. 

1 64. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 61, wherein said method further includes the 

4 step of generating historical reports of data relating 

5 to calls by customers users on said communications 

6 network with a client view application. 

1 65. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 61, wherein said method includes the step of 

4 generating electronic invoices and electronically 

5 transmitting funds to pay for preselected customer user 

6 calls. 

1 66 . The integrated and secure method for 

2 conducting business over the public Internet which 

3 enables a customer of an enterprise communications 

4. network to modify the customer's business relationship 

5 with the enterprise over the public Internet and to 

6 add, delete and modify services provided by the 

7 enterprise communications network to the customer, said 

8 method comprising: 

9 (a) enabling encrypted interactive 

10 communications between said system and said customer 

11 over the public Internet with an object oriented 

'2 protocol, said protocol invoked within said customers 

13 web browser to support encryption, customer 
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1 identification, authentication and network 

2 entitlements; 

3 (b) managing secure customer sessions over 

4 the public Internet with at least one secure web 

5 server, said secure server providing session management 

6 for the customer connection, said session management 

7 including customer identification, validation, 

8 entitlements and encryption; 

9 (c) communicating with said secure web 

10 server and a plurality of system resources with at 

11 least one dispatch server, said dispatch server 

12 providing verification of system access and proxy 

13 generation for said interactive communications after 

14 said customer's entitlements have been verified; 

15 (d) providing a plurality of system 

16 resources for the customer, said plurality including an 

17 order entry application which enables the customer to 

18 add, delete and modify services provided by the 

19 communications network to the customer, and to identify 

20 and authenticate a plurality of users with distinct 

21 call entitlements, and to modify said entitlements from 

22 a single point of customer identification and 

23 authentication . 

1 67 . The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 66, wherein said method further comprises the 

4 step of enabling electronic payment for said plurality 

5 of system resources with an E -Billing application, said 

6 order entry and E- Billing applications responsive to 

7 proxy requests from said dispatch server to enable the 

8 customer to electronically manage and pay for the 

9 communications network services provided by the 
10 enterprise. 
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1 68. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 66, wherein said method further includes the 

4 step of generating historical reports of data relating 

5 to calls by customers users on said communications 

6 network with a client view application. 

1 69* The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 66, wherein said method further includes the 

4 steps of generating invoices and enabling electronic 

5 payment for pre- selected customer user calls over the 

6 public Internet. 

1 70. The integrated * and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 66, wherein said method further includes the 

4 step of providing a toll free network manager 

5 application as one of said plurality of system 

6 resources to enable the customer to change toll free 

7 routing entitlements from said single point of customer 

8 identification and authentication. 

1 71. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 66, wherein said method further includes the 

4 step of providing managing calls to a call center with 

5 a call center manager application as one of said 

6 plurality of system resources, and said order entry 

7 application enabling a customer to identify and 

8 authenticate a plurality of users with distinct call 

9 center routing entitlements, and to modify said call 

10 center routing entitlements from said single point of 

11 customer identification and authentication. 
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1 72 . The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 66, wherein said method further includes the 

4 step of providing an event monitor application as one 

5 of said plurality of system resources. 

1 73 . The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 72, wherein said method further includes the 

4 step of reporting on data communications connections 

5 with a broadband view application. 

1 74. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 66, wherein said method further includes the 

4 step of managing trouble tickets generated with respect 

5 to said customers communications connections with a 

6 service inquiry application, and said order entry 

7 application providing modification of user entitlements 

8 with respect to said trouble tickets from said single 

9 point of customer identification and authentication. 

1 75. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 66, wherein said method further includes the 

4 step of monitoring communications traffic utilized by 

5 the customer with a real time monitor application as 

6 one of said plurality of system resources. 

1 76. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 66, wherein said method further includes the 

4 step of generating historical reports of data relating 

5 to calls by customers users on said communications 

6 network with a client view application. 
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1 77 . The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 76, wherein said method further includes the 

4 step of generating invoices for said calls with a 

5 priced reporting application and enabling electronic 

6 fund transfers with for payment of said calls with an 

7 E-Billing application. 

1 78. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 66, wherein said method includes the steps of 

4 providing a plurality of applications for the command 

5 and control of the customer's communications traffic 

6 over the enterprise communications network, and viewing 

7 said communications traffic with a reporting 

8 application. 

1 79 . The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 78, wherein said customer's communications 

4 traffic further includes switched voice traffic and a 

5 network manager application is provided for said 

6 command and control step. 

1 80. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 79, wherein said switched voice traffic 

4 further includes switched toll free voice traffic and 

5 said network manager includes a toll free network 

6 manager application to command and control the routing 

7 of said switched voice traffic. 

1 81. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 79, wherein said switched voice traffic 

4 further includes switched call center voice traffic and 
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1 said network manager includes a call manager 

2 application to command and control the routing of said 

3 switched voice traffic between call centers. 

1 82. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 79, wherein said switched voice traffic 

4 further includes switched toll voice traffic and said 

5 network manager includes an outbound network manager to 

6 command and control said switched toll traffic. 

1 83 . The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 78, wherein said customer's communications 

4 traffic further includes switched data communications 

5 and said method includes the step of viewing data 

6 representative of said switched data communications. 

1 84. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 78, wherein said customer's communications 

4 traffic further includes switched voice traffic and 

5 said method further includes generating reports on the 

6 switched voice traffic with a report generator 

7 application. 

1 85. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 84, wherein said step of generating reports on 

4 the switched voice traffic in said network traffic 

5 includes a real time reporter for generating reports on 

6 said network traffic in near real time. 

1 86. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 84, wherein said step of generating reports on 
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1 the switched voice traffic in said network traffic 

2 includes a reporter for generating history reports on 

3 said switched voice traffic occurring during 

4 preselected periods of time. 

1 87. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 84, wherein said step of generating reports on 

4 the switched voice communications in said network 

5 traffic includes a report manager application for 

6 enabling a customer to generate reports for a plurality 

7 of switched voice traffic applications and the step of 

8 storing aid report with an in-box manager application 

9 which communicates the reports to the customer. 

1 88. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 84, wherein said step of generating reports on 

4 the switched voice traffic in said network traffic 

5 includes a priced call application for enabling a 

6 customer to generate priced reports and invoices for a 

7 plurality of switched voice traffic applications. 

1 89 . The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 83, wherein said step of viewing said switched 

4 data communications is conducted with a broadband view 

5 application which generates reports on data relating to 

6 the switched data communications. 

1 90. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 89, wherein said method further includes 

4 storing and forwarding reports to the customer on data 

5 relating to the customer's switched data communications 

6 with an in-box application. 

-321- 



WO 99/15979 



PCT/US98/2O170 



1 91. The integrated and secure method for 

2 conducting business over the public Internet as claimed 

3 in Claim 90, wherein said viewing step includes storing 

4 and forwarding reports on alarm reports generated with 

5 respect to the customer's switched data communications 

6 with an event monitor application. 

1 92. An integrated and secure system for 

2 conducting business over the public Internet by 

3 enabling a reseller of an enterprise communications 

4 services to brand those services as those of the 

5 reseller over the public Internet for resale to a third 

6 party customer, said system comprising: 

7 (a) an object oriented protocol for enabling 

8 encrypted interactive communications between said 

9 system and said third party customer over the public 

10 Internet, said protocol invoked within said third party 

11 customer's web browser to support encryption, third 

12 party customer identification, authentication and 

13 entitlements; 

14 (b) at least one secure web server for 

15 managing secure third party customer sessions over the 

16 public Internet, said secure server providing session 

17 management for the third party customer connection, 

18 said session management including third party customer 

19 identification, validation, entitlements and 

20 encryption; 

21 (c) at least one dispatch server for 

22 communicating with said secure web server and a 

23 plurality of system resources, said dispatch server 

24 providing verification of system access and proxy 

25 generation for said reports after said third party 

26 customer's entitlements have been verified, each of 

27 said system resources maintaining data relating to 

28 separate communications network services provided to 
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1 the third party customer by the reseller of the 

2 enterprise resources; . . 

3 (d) a plurality of applications for enabling 

4 access to said system resources, each application 

5 having a backplane class for invocation within the 

6 third party customer's web browser to manage one or 

7 more company brands that may be presented by the 

8 application to the web browser of the third party 

9 customer, one of said one or more company brands 

10 representing a brand adopted by said reseller of 

11 communications services/ to enabling the reseller of 

12 communication services to represent said plurality of 

13 system resources as its own. 

1 93. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 16, wherein said reports are generated in real 

4 time with respect to the customer's switched 

5 communications connections by a real time monitor 

6 application, 

1 94. The integrated and secure system for 

2 conducting business over the public Internet as claimed 

3 in Claim 16, wherein said switched communications 

4 includes voice traffic, and said reports are generated 

5 in real time with respect to the customer's switched 

6 communications connections by a real time monitor 

7 application. 

1 95. The integrated and secure system for 

2 conducting business over the public Internet as 

3 claimed in Claim 30, wherein said single point of 

4 customer contact provides a click and connect dial up 

5 connection to a customer service representative of the 

6 enterprise. 
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